Re: Understanding Agrregates
| Newsgroups | gmane.comp.programming.domain-driven-design |
|---|---|
| Message-ID | <CAKqMafz9Lz8qHsnRDvF8BQJRcboUndHKGSEiMvhxydUKYHkk-g@mail.gmail.com> |
With aggregates, the trick is to look at your use cases and find out which set of entities/value objects can be/need to be persisted as one isolated unit (i.e. within one transaction). The rule of thumb within DDD Aggregates is that they are transaction boundaries and a good Domain Model allows, in 99% of the cases, at most one Aggregate to be persisted per transaction. So ask yourself this: do Customer and Account always need to be persisted together in the same transaction, or can one of them be updated in and of itself in different use cases? In the former case, they might form one Aggregate; in the latter, they are probably not. Regarding read operations, Aggregates are indeed usually loaded as a whole (especially when they are small or are serialized as one item), but this is not strictly necessary if not each use case requires all data of an aggregate. On Fri, Jul 11, 2014 at 2:05 AM, Michael Rempel [email protected] [domaindrivendesign] <[email protected]> wrote: > > > Always depends on how you USE it. What do you load together every time? > What single ID can you point to that says 'load that and everything > associated with it'. That is your aggregate root. > > Sometimes the answer is it depends. When it depends you likely have > several aggregate roots. Sometimes a single row is all you get. > > Remember this is just about the domain, not about reporting or > post-processing at all. > > > On Thu, Jul 10, 2014 at 10:26 AM, [email protected] > [domaindrivendesign] <[email protected]> wrote: > >> >> >> If I have a Customer and a Product and they are related by a Account. >> >> Account than is a Aggregate? >> >> >> I will have: >> Entity\Customer >> >> Entity\Product >> >> Aggregate\Account >> >> >> Or my Account still an Entity? >> >> > >