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?
>

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