Re: Understanding Agrregates

Oh you guys would have to go get all relevant and technical. For the most
part people who get transactions dont need to be told about aggregates.
However the impedence missmatch between them is not insignificant IMHO.


Ordinary cases of master detail asside, in an ongoing transformation (which
nearly everything important is one) The distinction gets harder to discuss.
I am suspecting that our use case here is one such muck bucket. The thing
to remember in THOSE cases is that you need a publication model. That means
states transition from one useful bucket of stuff to another useful bucket
of stuff. And the bucket full of bits that make up the transition is also
an aggregate. When you get enough of these and start to see patterns that
is when the big grok of value objects lands kerplunk in your lap.


Another thing that we should consider in DDD, but we dont have the model
for is the state space in the middle between one published set and the next
set. Even when the negotiation is in progress people will be told not to
use it, but to anticipate using it in some future sense. Sometimes
deadlines push a partial unofficial version of the published new set but it
is always red flagged internally as not publishable. The distinction is
important business logically, but not implementationally.


The thing to count on is that state transitions publish at various levels,
and their collection buckets are always also aggregates. Yes that means
never not so. Inside those aggregates we may have several smaller sets of
aggregates that are negotiated 'in department' (used loosely here, I think
you get it) but the official 'this is big, this is for ever, this is how we
do it now' or what ever else that sounds similar to that, those are the
things you should look carefully at for value objects because they matter.
But dont get too crazy about the divisions if you dont need to.


If you grok that the definition of an aggregate is one of the hardest
things to define, but one of the most effective at helping produce
performance you are starting to get it. Also think about what validation

rules fire when. If your parent never changes sometimes the detail level
specifics will fire rules on the parent that can produce different results.
If so then the child level MUST be updated through the parent aggregate.


If you have a million reports that only look at the child and never
consider the parent that is irrelevant. Reporting and your GUI read layer
are not part of deciding what an aggregate means.


I hope this helps. Your transactions and rules should help you get it. When
in doubt try to explain to yourself the things that MUST happen together,
regardless of where they live, who owns them, or how easy it is to prove
that it worked as planned. Think about it in database terms, but also in
business rules terms. Think about it in terms of if someone was trying to
break the system and you had to catch all their hacks and refuse to process
the problem child transactions every single time.






On Fri, Jul 11, 2014 at 2:05 PM, Paul Rayner [email protected]
[domaindrivendesign] <[email protected]> wrote:


>
>
> Leo,
>
> See https://github.com/paulrayner/ddd_sample_app_ruby, which also has
> links to the original Java and .NET versions. I talk about the port to Ruby
> at https://skillsmatter.com/skillscasts/4082-paul-rayner. About 14
> minutes into the presentation I walk through the aggregates.
>
> Cheers,
> Paul.
>
> On Fri, Jul 11, 2014 at 8:44 AM, Leo Cavalcante [email protected]
> [domaindrivendesign] <[email protected]> wrote:
>
>>
>>
>> Have you guys some projects samples of DDD using Aggregate hosted on
>> Github (or something)? 'll really appreciate!
>> And thanks for the answers.
>>
>>
>>  2014-07-11 11:35 GMT-03:00 Remy Fannader [email protected]
>> [domaindrivendesign] <[email protected]>:
>>
>>
>>>
>>> If accounts are identified by customers and cannot be transferred,  use
>>> composition
>>> If accounts are identified on their own but must be "aggregated" to
>>> single customers, use aggregate.
>>> Otherwise use association.
>>>
>>> http://caminao.wordpress.com/how-to-implement-symbolic-representations/patterns/functional-patterns/connector-patterns/
>>> Rémy.
>>>
>>>
>>
>  
>