> Banking systems are also extremely advanced. A personal bank account differs a lot from a business bank account, and there are at least 50 different types of bank accounts for each of them.
I wouldn't necessarily call that "advanced"... maybe more, lacking in requirements-analysis-time insight in ways to factor the business-domain into HAS-A component relationships, such that individual components and their ADTs can be shared across parent types [which are really just template/factory objects for a smaller set of actual types], and initialized with simple parameters that get used as formula variables with no piecewise logic.
To be clear, I write this as someone who works for a company that maintains a unified representation of data across the blockchain ecosystem — where each blockchain has its own peculiarities about what an "account" is, what a "transaction" can do, etc. Our data model only has one toplevel account type, one toplevel ledger-transaction type, etc. To handle the peculiarities, our data model instead has a large heirarchy of smaller data-objects hanging off of those toplevel ones; where any given data-object is sort of an "optional extension" that may or may not be there depending on how the toplevel object was created.
This approach allows us to just have one unified code-path that treats every account like every other account, every tx like every other tx, etc. We don't have duplicate code or a hierarchy of subclasses that all do things slightly differently; but instead, for any ledger-transaction, there may or may not be e.g. a strategy-pattern object hanging off that tx — and if there is, it gets used instead of the default
static one. It's great for maintainability, testability, predictability, cacheability, and hundreds of other things.
I'd love to know if there's any good reason that a bank would actually want "50 different types of bank account" on an implementation level, rather than these all boiling down to one type with varying values of certain state variables + presence/absence of certain foreign-key relationships.
Other than maybe "some of these account types are actually a part of completely different data models living in third-party systems, that we acquired, and then never merged into our own systems." ;)
> I'd love to know if there's any good reason that a bank would actually want "50 different types of bank account" on an implementation level.
Not having the benefit of hindsight?
Some banks are hundreds of years old. Most of them were computerized seventy years ago if not earlier, back in the stone age of computers. These kinds of banks won't bet the house on a newfangled system every couple of years because some bright-eyed engineer told them it's the trend nowadays.
Not messing up their bookkeeping is their number one priority. People would riot if their bank told them "sorry, we no longer know how much money you had deposited with us".
> These kinds of banks won't bet the house on a newfangled system every couple of years because some bright-eyed engineer told them it's the trend nowadays.
The thing about banking, is that they keep records of everything — not just "state now", but all previous states, and all the state deltas, and all the commands that produced those deltas, and an audit log of who/where/when the requests were made to triggered those commands. Financial-ledger databases are the original CQRS event-streaming reducer systems.
And this actually means that it's very easy to produce a new system that is provably "at parity with" an existing system. No faith required. You take your complete historical CQRS event stream from your existing system, stream it through the new system, and see that it produces the same state that's in the existing system. If it does — and if you're operating on years of real data — then that's more evidence for exact parity than a test suite would ever be.
(You may also want to produce hypothetical CQRS command streams and run them through both the existing and new systems. This would mostly be useful for regression-testing of edge-case logic that is required for e.g. compliance, but so rare that it has yet to ever actually come up in practice.)
> Most of them were computerized seventy years ago if not earlier, back in the stone age of computers.
You can do everything I mentioned — factoring out your business rules into simpler rules that apply to a collection of orthogonal sub-ledgers — on paper. These ideas are not "newfangled"; while they were introduced into computing through the formalism of relational algebra (as database normalization), the ideas existed well before the mathematical formalism for them existed. Clever people have been simplifying their paper records into orthogonal sub-ledgers since the invention of double-entry book-keeping in 1494.
Kinda makes you wonder if anyone opened an account then and deposited a dollar ("daler" in Swedish), and let it sit and accrue interest for the family for 350 years.
I wouldn't necessarily call that "advanced"... maybe more, lacking in requirements-analysis-time insight in ways to factor the business-domain into HAS-A component relationships, such that individual components and their ADTs can be shared across parent types [which are really just template/factory objects for a smaller set of actual types], and initialized with simple parameters that get used as formula variables with no piecewise logic.
To be clear, I write this as someone who works for a company that maintains a unified representation of data across the blockchain ecosystem — where each blockchain has its own peculiarities about what an "account" is, what a "transaction" can do, etc. Our data model only has one toplevel account type, one toplevel ledger-transaction type, etc. To handle the peculiarities, our data model instead has a large heirarchy of smaller data-objects hanging off of those toplevel ones; where any given data-object is sort of an "optional extension" that may or may not be there depending on how the toplevel object was created.
This approach allows us to just have one unified code-path that treats every account like every other account, every tx like every other tx, etc. We don't have duplicate code or a hierarchy of subclasses that all do things slightly differently; but instead, for any ledger-transaction, there may or may not be e.g. a strategy-pattern object hanging off that tx — and if there is, it gets used instead of the default static one. It's great for maintainability, testability, predictability, cacheability, and hundreds of other things.
I'd love to know if there's any good reason that a bank would actually want "50 different types of bank account" on an implementation level, rather than these all boiling down to one type with varying values of certain state variables + presence/absence of certain foreign-key relationships.
Other than maybe "some of these account types are actually a part of completely different data models living in third-party systems, that we acquired, and then never merged into our own systems." ;)