Re: Understanding Agrregates

Can I have a hole domain model structure without any Aggregate? Or that 'll

be a symptom that something is wrong? I always 'll need one or another
Aggregate?




2014-07-11 3:55 GMT-03:00 Wim van Gool [email protected]
[domaindrivendesign] <[email protected]>:


>
>
> Oh, and I wanted to add that when you are doing DDD, try not to become
> fixated on a model with 'Customers' and 'Accounts' that looks much like the
> traditional Data Model you had in mind. Not that having those sort of
> entities in your model is wrong per se, but before you start talking about
> 'which entities are aggregates', do it the other way around: which use
> cases do I have, and which aggregates do I need to be able to execute each
> use case in one and only one transaction? Then start asking yourself
> whether certain items in your model are real entities and which can serve
> as value objects (and prefer the latter where possible).
>
>
>
>
> On Fri, Jul 11, 2014 at 8:48 AM, Wim van Gool <[email protected]> wrote:
>
>> 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?
>>>>
>>>>
>>>
>>
>  
>