DDD (Domain-Driven-Design) - large units

Question

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

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

BankAccount BigDecimal calculateTurnover(); 

BankAccount is an aggregate. To calculate the turnover, I have to go through all the transactions and summarize all the amounts. Evans suggests that I should use repositories to download aggreagates only. In the above case, there may be several transactional transactions that I do not want to load immediately into memory.

In the context of the repository template, aggregate roots are the only objects> your client code is loaded from the repository.

The repository encapsulates access to child objects - from the point of view of the caller, it automatically downloads them, either at the same time when the root is loaded, or when they are really needed (as with lazy loading).

What will be your proposal to implement calulcateTurnover in the DDD aggregate?

Answer 1

As you pointed out, loading 1000 objects in an aggregate is not a scalable solution. Not only will you run into performance issues, but you will probably also run into concurrency problems, as Won Vernon emphasized in his Effective Build Design .

Do you want each transaction to be available in BankAccount or do you BankAccount only to turnover?

If this is just the turnover you need, then you should set this value when creating your BankAccount aggregate. This can probably be calculated efficiently by your data storage technology (indexed JOINs, for example, if you use SQL). Perhaps you also need to think of it as a predefined value in your data warehouse (what happens when you start dealing with millions of transactions in a bank account)?

But maybe you still need the transactions available in your domain? Then you should consider hosting a separate Transaction repository.

I would highly recommend reading the Vaughn Vernon series on aggregate design as above.

Answer 2

You managed to pick up a very interesting example :)

I use Account 1 → * Transaction when explaining an event source (ES) to anyone who is not familiar with it.

As a developer, I was taught (back) to use what we can now call the interaction of entities. So, we have a Customer record, and it has the current state. We somehow change the state of the record (address, tax data, discounts, etc.) and save the result. We never know what happened, but we have the last state, and since this is the current state of our business, everything is in order. Of course, one of the first issues we had to deal with was concurrency, but we had ways to deal with it, and although this is not fantastic, it "worked."

For some reason, accounting discipline didn’t quite consist in this. Why we do not just have the last state Account . We will download the corresponding record, change the balance and save the state. Oddly enough, most people will probably cringe at the thought, but it seems that everything is fine for the rest of our data.

The accounting area goes around this by logging change events as a sequence of Transaction records. Thus, if you lose your account and last balance, you can always start all transactions to get the last balance. This is a source of events.

The ES typically loads the entire list of events for the cumulative root (AR) to obtain its last state. There is also, as a rule, a mechanism to deal with a huge number of events when loading all of them can cause performance problems: snapshots. Usually, only the last snapshot is saved. The snapshot contains the complete state of the aggregate and only event after applying the snapshot.

One of the great benefits of ES is that you could find new queries, and then simply apply all the events to the query processor and determine the result. Perhaps something like: "How many clients do I have that have moved twice in the last year." Quite arbitrary, but using the "traditional" approach, it is likely that we will begin to collect this information from today and have it next year, since we do not save CustomerMoved events. With ES, we can search for CustomerMoved events and get results anywhere.

So this brings me back to your example. You probably do not want to download all transactions. Instead, save the Turnover and calculate it on the go. If Turnover is a new requirement, then one-time processing of all ARs should bring it up to speed. You can still have the calculateTurnover() method, but that would be too often. And in these cases, you will need to download all transactions for AR.