> 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.
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".