> 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.<p>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.<p>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 <i>one</i> toplevel account type, <i>one</i> 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.<p>This approach allows us to just have one unified <i>code-path</i> 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 <i>any</i> 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.<p>I'd love to know if there's any <i>good</i> reason that a bank would actually <i>want</i> "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.<p>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." ;)