Re: Re: CQS

> > Does the aggregate root fire a message when it's done adding/ 
> processing an order, which the reporting context subscribes to?
>
> It’s actually the bounded context, but yes. More specifically, the  
> service layer which processed the message by calling a method on the  
> aggregate root would do the publishing.

This raises an interesting question - I thought if you were using  
Event Sourcing, then the Aggregate Roots would be processing the  
events as well. ie, That you'd have an  
MyAggregateRoot.ProcessOrder(ProcessOrderEvent) method or something  
similar - and then this would apply whatever state changes were  
necessary on the domain objects and fire some sort of completed event.

In Fowler's Event Sourcing patterns, he prefers the processing logic  
on the Events themselves where possible. This certainly makes a lot of  
sense for the reasons he elicits, but in a DDD context, does that then  
lead to anaemic domain objects as most of the logic is contained in  
the Events themselves?

If the domain objects became the event processors instead, then you'd  
have more of the state changing logic encapsulated on the domain  
objects themselves - but you'd also run into the issue that your  
domain objects are now event-aware, and is this something that they  
should "know" about? Perhaps the answer to this depends on whether  
"Events" are a part of your Ubiquitous Language in your domain or not.  
This could probably be argued back and forth a lot - as one could  
probably equally have the same argument over explicit methods (are  
"Methods" part of your Ubiquitous Langauge?) Whether your domain  
objects are processing event objects or more fundamental types as  

Re: Re: Quick naming question

What about Factository? Repactory?

Rich

------------------------------------

Re: Re: CQS

> The algorithm you described can be a standalone component (data in,  
> data out, no state) used by multiple parts of the system.

That's right - hence my earlier suggestion to refactor it into a  
shared TotalCalculator - but even still, the algorithm will need to  
use objects with state to perform its calculation.

Sometimes these will be primitive types, but other times they may be  
domain objects (for example, an AssetCondition Value Object). If these  
domain objects are encapsulated by Aggregate Roots which exist in a  
separate Bounded Context, then how is the Presentation layer supposed  
to instantiate them to pass into this "standalone component"? Do you  
put all of these domain objects into your Shared Kernel and give the  
Presentation access that way? Or do you try to extract all of the data/ 
state from your domain objects into primitive types and generic  
dataholders before passing them to the calculation function?

The answer to this may lie in the answer to the question of whether a  
Presentation layer is considered a completely separate Bounded  
Context(s) or not - which I'll start another thread for as I've got  
some other questions around this too.

------------------------------------

Re: CQS

Nice interview BTW Greg - it addresses some of the things raised on  
this thread, and others (although of course there's still a myriad of  
unanswered questions...)

http://www.infoq.com/interviews/greg-young-ddd

On 27/01/2009, at 4:47 AM, Greg Young wrote:

> Many have brought up some good questions in regard to CQS in the few
> threads currently going on the subject.
>
> Most of these are good an valid questions. These questions are quite
> valuable to me as although they are not new questions they can create
> for me an early FAQ in my work that addresses them.
>
>
>
>
> Would it be possible for people to summarize their questions here? It
> is just a bit hard to manage with them sprinkeled throughout 100+
> posts in 3 threads.
>
> Thanks in advance,
>
> Greg
>
> -- 
> It is the mark of an educated mind to be able to entertain a thought
> without accepting it.
>

RE: Re: CQS

Aggregate Roots as separate non-Entity objects (like a type of Domain Service?)

While I realise that one of the properties of an Aggregate is to  
choose an Entity that serves as the root of that boundary, is everyone  
actually using that Entity class to serve as the contract of the  
boundary itself? Or do you use a separate object (eg,  
CustomerAggregateRoot) that serves this purpose, which in turn holds a  
reference to the root Entity (Customer)?

The main reason that I ask is that it strikes me that the root Entity  
would end up with a lot of responsibility if it's controlling all  
external access, as well as acting as a transactional boundary and  
enforcing all the invariants of the contained objects - as well as all  
of the regular domain behaviour specific to the Entity itself.  
Basically it feels a bit like an unnecessary violation of SRP - not  
that principles always apply, but still...

If you had a separate Aggregate Root object, it strikes me that it  
might be beneficial to view it as a specific type of Domain Service -  
ie, one that only deals within one Aggregate boundary. As with other  
Services, it would have the responsibility of dealing with explicit  
Units of Work, invoking Repository methods and processing external  
messages (if that's the way you swing). And then there'd be Aggregate- 
specific responsibilities like exposing externally required Factory  
methods.

Does anyone do this? Or do people find the responsibilities of being  
an Aggregate Root still fit nicely on the root Entity itself?

------------------------------------

Re: Aggregate Roots as separate non-Entity objects (like a type of Domain Service?)

Hi Michael!

Without actually knowing how such an aggregate might look like, I still 
would not use a separate object action as some kind of root entry 
object. Using a separate root object also would be violating SRP in some 
way, just shifting the problem up.

Generally it has to be said, whenever your aggregate becomes that 
complex, you have a kind of design smell and actually are trying to put 
all your domain logic and entities as children of one god object, that 
at first sight might be the root. But then you could also have a 
DomainAggregateRoot...

And the case of violating SRP:
The entities inside an aggregate still have their own responsibilities, 
don't they. Or are they all just anemic entities? I suppose not.

My suggestion would be: if it seems that the aggregate root entity has 
to much responsibility or has many methods that just delegate to its 
ivolved entities then rethink your aggregate layout.

But it's hard to guess the needs without practical examples.
It seems to me that you are really talking about a domain service 
managing many aggregate roots.

Michael Hart wrote:
> While I realise that one of the properties of an Aggregate is to
> choose an Entity that serves as the root of that boundary, is everyone
> actually using that Entity class to serve as the contract of the
> boundary itself? Or do you use a separate object (eg,
> CustomerAggregateRoot) that serves this purpose, which in turn holds a
> reference to the root Entity (Customer)?
 >
> The main reason that I ask is that it strikes me that the root Entity
> would end up with a lot of responsibility if it's controlling all
> external access, as well as acting as a transactional boundary and
> enforcing all the invariants of the contained objects - as well as all
> of the regular domain behaviour specific to the Entity itself.
> Basically it feels a bit like an unnecessary violation of SRP - not
> that principles always apply, but still...
> 
> If you had a separate Aggregate Root object, it strikes me that it
> might be beneficial to view it as a specific type of Domain Service -
> ie, one that only deals within one Aggregate boundary. As with other
> Services, it would have the responsibility of dealing with explicit
> Units of Work, invoking Repository methods and processing external
> messages (if that's the way you swing). And then there'd be Aggregate-
> specific responsibilities like exposing externally required Factory
> methods.
> 
> Does anyone do this? Or do people find the responsibilities of being
> an Aggregate Root still fit nicely on the root Entity itself?

------------------------------------

Re: Aggregate Roots as separate non-Entity objects (like a type of Domain Service?)

Re: Aggregate Roots as separate non-Entity objects (like a type of Domain Service?)

Hi,
In my case I don't use any separate CustomerAggregateRoot class, if
from domain perspective Customer is decided to be root then the class is
marked as aggregate with an interface, just to constraint it for
repositories.  
To solve SRP problem I usually delegate responsibilities from Root to
the specific classes i.e. for class invariants I use validation rules,
or specifications, for iterations external iterator classes, etc. I
would recommend to use various patterns in order to delegate and\or
attach new behavior without breaking SRP or SoC.
Hope this helps,
Artur Trosin

--- In domaindrivendesign <at> yahoogroups.com, Michael Hart
<michael.hart.au@...> wrote:
>
> While I realise that one of the properties of an Aggregate is to
> choose an Entity that serves as the root of that boundary, is everyone
> actually using that Entity class to serve as the contract of the
> boundary itself? Or do you use a separate object (eg,
> CustomerAggregateRoot) that serves this purpose, which in turn holds a
> reference to the root Entity (Customer)?
>
> The main reason that I ask is that it strikes me that the root Entity
> would end up with a lot of responsibility if it's controlling all
> external access, as well as acting as a transactional boundary and
> enforcing all the invariants of the contained objects - as well as all
> of the regular domain behaviour specific to the Entity itself.
> Basically it feels a bit like an unnecessary violation of SRP - not
> that principles always apply, but still...
>
> If you had a separate Aggregate Root object, it strikes me that it
> might be beneficial to view it as a specific type of Domain Service -
> ie, one that only deals within one Aggregate boundary. As with other
> Services, it would have the responsibility of dealing with explicit
> Units of Work, invoking Repository methods and processing external
> messages (if that's the way you swing). And then there'd be Aggregate-
> specific responsibilities like exposing externally required Factory
> methods.
>
> Does anyone do this? Or do people find the responsibilities of being
> an Aggregate Root still fit nicely on the root Entity itself?
>

------------------------------------

Re: Aggregate Roots as separate non-Entity objects (like a type of Domain Service?)

SRP says: "There should never be more than one reason for a class to
change."  Or conversely, there should be an equal likelihood of
changing any of the class' members.

It seems that any change to Customer would imply a change to a
CustomerAggregateRoot.  The question then is, could you foresee any
change to CustomerAggregateRoot which isn't dependent on a change to
Customer.  If so, then you should probably separate the two out. 
Otherwise not.

That said, I wouldn't ever discuss think of CustomerAggregateRoot as
part of the UL.  But it could conceivably be part of the technical
plumbing dependent on how you've implemented the other layers of your
app.  For myself, I would never introduce such a class; there would be
no need using my preferred technology framework.

Dan 

--- In domaindrivendesign <at> yahoogroups.com, Michael Hart
<michael.hart.au@...> wrote:
>
> While I realise that one of the properties of an Aggregate is to  
> choose an Entity that serves as the root of that boundary, is everyone  
> actually using that Entity class to serve as the contract of the  
> boundary itself? Or do you use a separate object (eg,  
> CustomerAggregateRoot) that serves this purpose, which in turn holds a  
> reference to the root Entity (Customer)?
> 
> The main reason that I ask is that it strikes me that the root Entity  
> would end up with a lot of responsibility if it's controlling all  
> external access, as well as acting as a transactional boundary and  
> enforcing all the invariants of the contained objects - as well as all  
> of the regular domain behaviour specific to the Entity itself.  
> Basically it feels a bit like an unnecessary violation of SRP - not  
> that principles always apply, but still...
> 
> If you had a separate Aggregate Root object, it strikes me that it  
> might be beneficial to view it as a specific type of Domain Service -  
> ie, one that only deals within one Aggregate boundary. As with other  
> Services, it would have the responsibility of dealing with explicit  
> Units of Work, invoking Repository methods and processing external  
> messages (if that's the way you swing). And then there'd be Aggregate- 
> specific responsibilities like exposing externally required Factory  
> methods.
> 
> Does anyone do this? Or do people find the responsibilities of being  
> an Aggregate Root still fit nicely on the root Entity itself?
>

------------------------------------