| Newsgroups |
gmane.comp.programming.domain-driven-design |
| Message-ID |
<[email protected]> |
I agree that aggregate should be fully populated, but it's often useful to have only a projection of the aggregate. Problem is that people dislike adding a new specialized type and instead try to reuse existing one. My solution was to make it cheap to create a snowflake out of aggregate and thus improve the domain instead of trying and shoehorning it into an existing aggregate.
It's perfectly fine to create new aggregates, especially when the domain allows it. No need to introduce additional concepts into the domain, since the domain is simplified model of the reality.
I often find strange that people have aggregates and entities in their domain model, but have only entities in the database. To me this looks like disaster waiting to happen since your boundary which you carefully constructed in the code, breaks down when data goes to persistence. Now onto your specific example...
Are tires and steering wheels entities or aggregates?
If they are aggregates, you can't really make car boundary around them, but you are free to assign them (even by just passing along their identity)
If they are entities, then you ought to assign them as a whole anyway instead of by identity, since entities (even if they mathematically have identity) should not be passed around by identity.
So yeah, people who pass in ID of the entity object to create an aggregate and not really following the spirit of the DDD, but sometimes this is the best choice with the technology stack you use ;(
I personally don't bother with EF and use much better databases for DDD than MsSql so I don't run into those problems ;)
Regards,
Rikard