DDD (Domain-Driven-Design) - large aggregates

Question

I'm currently studying Eric Evans'es Domain-Driven-Design. The idea of aggregates is clear to me and I find it very interesting. Now I'm thinking of an example of aggregate like :

BankAccount (1) ----> (*) Transaction.

BankAccount
BigDecimal calculateTurnover();

BankAccount is an aggregate. To calculate turnover I should traverse all transactions and sum up all amounts. Evans assumes that I should use repositories to only load aggreagates. In the above case there could be a few tousands of transactions which I don't want load at once in memory.

In the context of the repository pattern, aggregate roots are the only objects > your client code loads from the repository.

The repository encapsulates access to child objects - from a caller's perspective it automatically loads them, either at the same time the root is loaded or when they're actually needed (as with lazy loading).

What would be your suggestion to implement calulcateTurnover in a DDD aggregate ?

Answer 1

As you have pointed out, to load 1000s of entities in an aggregate is not a scalable solution. Not only will you run into performance problems but you will likely also experience concurrency issues, as emphasised by Vaughn Vernon in his Effective Aggregate Design series.

Do you want every transaction to be available in the BankAccount aggregate or are you only concerned with turnover?

If it is only the turnover that you need, then you should establish this value when instantiating your BankAccount aggregate. This could likely be effectively calculated by your data store technology (indexed JOINs, for example, if you are using SQL). Perhaps you also need to consider having this this as a precalculated value in your data store (what happens when you start dealing with millions of transactions per bank account)?

But perhaps you still require the transactions available in your domain? Then you should consider having a separate Transaction repository.

I would highly recommend reading Vaughn Vernon's series on aggregate design, as linked above.