28 lines
2.1 KiB
Markdown
28 lines
2.1 KiB
Markdown
Collection of objects clustered together for the purpose of data changes. Designed to keep data transactionally consistent.
|
|
|
|
> Like splitting orders into orderlines. Maybe view them as very closely coupled models/ entities. Something where the main model owns the interface with the world. So the root entity
|
|
|
|
A design consideration is the size of the aggregate, as storing race conditions become a problem. To find a boundary consider the need for consistency, if transactional consistency is needed it is likely within the aggregate. It could well be that most aggregate consist of a single entity, the root.
|
|
|
|
> If eventual consistency is fine. Maybe store this in another aggregat and couple them using a event.
|
|
|
|
Not every use case that modifies multiple aggregates warrants the combining of the aggregates into a single one. First find out if eventual consistency is acceptable. Domain experts are often more comfortable with eventual or delayed consistency. This happens in the real world all the time.
|
|
|
|
>But don't forget to tell them!!!
|
|
|
|
>A way to force an aggregate is to keep its relation methods private. Keeping it's interaction going through the root model.
|
|
|
|
Or consider single use actions / commands. There are however reasons for changing multiple aggregates in a single transaction.
|
|
- User Interface Convenience, think bulk editsor simply complex interfaces. This does not mean all the aggrates involved should be a single aggregate.
|
|
- Not having the technical means to do eventual consistency. Or introducing it for a single case.
|
|
- Global transactions Transactions spanning multiple domain
|
|
- Database preformance. All the data is there, just use it.
|
|
|
|
## Implementing Eventual Consistency
|
|
An event is published which then wakes some listener. While this is happening in the background, the user may need to be informed by some visual indication of the system stil being in transit.
|
|
> Frame automation like a college doing the work for you but it may take some time before they get to it.
|
|
|
|
> Build in a version attribute into each Roof Entity. This way depenancies are clear and we can speak of a real version.
|
|
|
|
No dependency injection into an aggregate.
|