Menu
In Domain-driven design if I want to use a repository I need to have an aggregate for it - as I understand.
So I have a User, that has id, login, email, and password. A user is a domain Entity with unique Id.
When i want to add a User to User repository, should I build first an Aggregate with only Aggregate Root that is my User entity and nothing more? It looks like a proxy to User in this case, unneeded layer.
Or maybe I missed something here? Maybe User isnt an Entity, even if it looks like this. Or maybe I can put an Entity directly to repository?
791
As you rightly pointed out, Entity instances shouldn't be shared between aggregates, as one aggregate wouldn't be aware of changes to the entity made through another aggregate and couldn't enforce its invariants.
Entity has meaning (and therefore an id) defined outside of the state of its values as oppose to "value objects" whose identity is defined entirely by its state. Aggregate a structure of internally consistent and logically related "things" which might be entities or value objects.
Aggregate is a pattern in Domain-Driven Design. A DDD aggregate is a cluster of domain objects that can be treated as a single unit.
[Evans] states that one Aggregate may hold references to the Root of other Aggregates. However, we must keep in mind that this does not place the referenced Aggregate inside the consistency boundary of the one referencing it. The reference does not cause the formation of just one whole Aggregate.
An aggregate root (AR) is an entity and it's very common to have entities which are the root of their own aggregate.
Your User entity would simply be an aggregate root. You do not need an extra concrete class.
114
In Domain-driven design if I want to use a repository I need to have an aggregate for it - as I understand.
An important thing that I would like to raise is that we don't create aggregates for repositories, we create repositories because we need to persist aggregates.
Repositories deal with whole aggregates, nothing more and nothing less. They preserve the transactional boundary which is what should define your aggregate.
When i want to add a User to User repository, should I build first an Aggregate with only Aggregate Root that is my User entity and nothing more? It looks like a proxy to User in this case, unneeded layer.
There is absolutely nothing wrong with single-entity aggregates. An entity in this case will be the aggregate root and the entirety of the aggregate.
I would recommend that you read Vaughn Vernon's Effective Aggregate Design series.
44
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
