search

SAP / curated-resources-for-domain-driven-design

You want to get started with Domain-Driven Design or are looking for advanced learning resources in this topic? Then this collection of curated learning resources is a good place to check out.
Apache License 2.0
149 stars 19 forks source link

feat(blog): Aggregates - How to model & how to dev #26

Closed neolytian closed 1 year ago

neolytian commented 1 year ago

Contains to blog summarising:

  1. How to model aggregates
  2. How to develop aggregates with examples
lechnerc77 commented 1 year ago

Super generic comment on aggregates and how to describe them and maybe different angle (and may also support in filling the aggregate design canvas), maybe t helps, maybe not:

The aggregate lives within one bounded context. It can be interpreted as a container for state. The container can be moved from one state to another. These state transitions are triggered by commands. Whenever the container is in one state it is completely consistent. The consistency is defined from a business perspective by the invariants basically telling what is allowed and what is not allowed. Whenever a state change happens (or cannot happen due to invariants one or more business events are raised, informing the "world" about the change. Whenever an aggregate is in a (consistent) state it can be persisted

The scalability of the system and the size of the aggregate are in direct relation. However this has impact on the handling of cross-aggregate consistency => it is easier from a developer perspective to have one aggregate per bounded context and keep that consistent. The price is that your system will only scale (or not) based on this one big aggregate. The other way round when the design foresees smaller aggregates you can scale them independently but will probably have to wrap you head around compensation.

Non-business example: A chess tournament.

The aggregate in this case will probably be a single chess game/board. The actions are the movements of the chess pieces on the board and the invariants are the rule of the chess game wrt to the allowed movements of the chess pieces. With this design/size of the aggregate we can cover basically every size of a tournament as the unit is the single game which can scale independently. One could now make some thought-experiments and gets an idea about the consequences concerning changing the size of the aggregate even to the extreme to have a whole tournament as one aggregate.

neolytian commented 1 year ago

Super generic comment on aggregates and how to describe them and maybe different angle (and may also support in filling the aggregate design canvas), maybe t helps, maybe not:

The aggregate lives within one bounded context. It can be interpreted as a container for state. The container can be moved from one state to another. These state transitions are triggered by commands. Whenever the container is in one state it is completely consistent. The consistency is defined from a business perspective by the invariants basically telling what is allowed and what is not allowed. Whenever a state change happens (or cannot happen due to invariants one or more business events are raised, informing the "world" about the change. Whenever an aggregate is in a (consistent) state it can be persisted

The scalability of the system and the size of the aggregate are in direct relation. However this has impact on the handling of cross-aggregate consistency => it is easier from a developer perspective to have one aggregate per bounded context and keep that consistent. The price is that your system will only scale (or not) based on this one big aggregate. The other way round when the design foresees smaller aggregates you can scale them independently but will probably have to wrap you head around compensation.

Non-business example: A chess tournament.

The aggregate in this case will probably be a single chess game/board. The actions are the movements of the chess pieces on the board and the invariants are the rule of the chess game wrt to the allowed movements of the chess pieces. With this design/size of the aggregate we can cover basically every size of a tournament as the unit is the single game which can scale independently. One could now make some thought-experiments and gets an idea about the consequences concerning changing the size of the aggregate even to the extreme to have a whole tournament as one aggregate.

I have added this text with minor adoption into the blog. I really like it.

neolytian commented 1 year ago

@lechnerc77 and @mr-flannery could you please re-check and give me your thumbs up?