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.

  • I would suggest programming anything that uses an Account to instead use an IAccount interface (or a more fine-grained break-down therein). – king-side-slide 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. – king-side-slide Oct 12 '18 at 16:27
  • FWIW, I find eliminating dependencies more important/valuable than eliminating duplication. – king-side-slide 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