0

So one thing you do not hear much about is inheritance with DDD. Currently I have an Account aggregate that handles details regarding a financial account and its subaccounts. Then a Transaction aggregate is used that maintains the invariants related to a financial transaction. The transaction is not a split transaction (yet), but links a credited account and debited account (via entity IDs).

When I compute the balance of an account, I use a domain service that takes in an AccountId and uses the AccountRepository and TransactionRepository to compute the balance.

So far so good, until I get to the idea of tracking investment accounts. This changes how the balance is computed. I need to use the last known share price with the amount of shares purchased to compute the balance.

So with different behavior, it makes sense to have an InvestmentAccount class that inherits from Account. However, I'm stuck on how to handle this with regards to using inheritance/polymorphism.

I do not want to have switch statements littered through my code so I thought polymorphism would be the answer. However, re-instantiating a supertype isn't as easy as I suspected.

Am I missing a separate aggregate here? I had the idea of using the Strategy pattern to inject a different algorithm for computing the balance. But behavior isn't the only different. I still need a way to track shares vs dollar amounts so that only gets me half of the way. This makes me think I need another class InvestmentAccount.

keelerjr12
  • 1,199
  • 1
  • 9
  • 22
  • I would suggest programming anything that uses an `Account` to instead use an `IAccount` interface (or a more fine-grained break-down therein). – user3347715 Oct 12 '18 at 16:22
  • I'm actually thinking I have multiple Boundary Contexts here. One corresponding to Accounting and another related to Investments. For example, the accountant probably does not care what exactly the current share price is or even what the investment is. And the investment manager does not care where the money came from (from an accounting perspective), but he does care about the number of shares and what the current share price is. I believe by splitting this up I can better align responsibilities. – keelerjr12 Oct 12 '18 at 16:22
  • I mention an interface because you seem to be using both account types interchangeably (your note of switch statements), but a complete separation into different BCs may also be the best approach if the management and use of such accounts needn't overlap. – user3347715 Oct 12 '18 at 16:27
  • FWIW, I find eliminating dependencies more important/valuable than eliminating duplication. – user3347715 Oct 12 '18 at 16:28
  • @king-side-slide does this imply you would even consider a `CashAccount` and `ShareAccount` that have some of the similar behavior and then use a `CashAccountRepository` and a `ShareAccountRepository`? – keelerjr12 Oct 12 '18 at 16:30
  • Two aggregates would necessarily need to repositories, yes. If there is application-level code that *coordinates* your accounts according to their "similar" behavior (e.g. `Account.Balance`), then you may, instead of using inheritance, simply define an `IAccount` interface that serves as a contract. Inheritance is very tricky to model in terms of persistence/hydration. Usually, in DDD, data is split *vertically* according to behavior. With inheritance (I will assume single-table inheritance as this is the simplest to implement), it requires your data to be split horizontally. This adds... – user3347715 Oct 12 '18 at 16:38
  • ... a second dimension when querying. So instead of simply querying different fields/tables, you will be partitioning your queries according to a user-defined field (e.g. `[AccountType VARCHAR(10)]`). Additionally, it may imply that the same fields in the same table may have different validation requirements. Having two repositories/aggregates alleviates the need to combine all of this extra logic. This simplifies your system. – user3347715 Oct 12 '18 at 16:42

0 Answers0