Discussion of the domain-driven style of designing software ()

Dan Haywood | 1 Feb 13:18

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

(Continue reading)

headers

Michael Hart | 1 Feb 14:26

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

> It seems that any change to Customer would imply a change to a
> CustomerAggregateRoot.

Probably... although there may be behaviour that doesn't need to be  
exposed outside of the Aggregate (and hence is not part of the  
external contract). Responsibilities that are required by other  
objects in the Aggregate for example, but maybe there's very little of  
this behaviour in reality (with most behaviours being initiated from  
the root Entity anyway).

>  The question then is, could you foresee any
> change to CustomerAggregateRoot which isn't dependent on a change to
> Customer.

This perhaps depends, as you say, on how much plumbing you do on your  
Aggregates and how much you do on Services. I have thought of Services  
as being co-ordinators *between* Aggregate Roots, but if you're not  
putting any infrastructure concerns in the Aggregate Root, then you'd  
essentially need a pass-through Service for each Aggregate (ie, one  
whose contract reflects the Aggregate Root contract). Not that this is  
a big problem, but I imagine they might be fairly anaemic Services.

An Aggregate may also have exposed Factory methods, for creating Value  
Objects or returning transient references to other Entities - these  
are responsibilities that the Entity would not have were it not the  
Aggregate Root.

In the absence of any real-world example, these reasons probably  
aren't compelling enough though. And it's good to hear that these  
concerns haven't affected you in reality either.

(Continue reading)

headers

Sebastian Jancke | 1 Feb 20:49

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

Hi,

(i will aggregate some of your mails and answer in one move...)

> 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

External clients should not beware of the internals, thus they can only 
access the overall behavior of the aggregate itself - and not any tiny 
internal behavior bits. So it's not a lot.
Transactional boundaries are managed by your infrastructure. The nature 
and design of an aggregate helps to express this and makes it possible 
to do it.
Speaking of an Entities behavior, I like to move as much as I can into 
Value objects and coordinate and delegate in an Entity.

Why do we follow SRP? To manage change (and prevent Shotgun surgery). So 
what implies a modification of an aggregate root? To me only a change in 
the aggregates behavior.

> Probably... although there may be behaviour that doesn't need to be
> exposed outside of the Aggregate (and hence is not part of the
> external contract). Responsibilities that are required by other
> objects in the Aggregate for example,

Internal behavior is provided by aggregate's internal objects: Value 
Objects and Entities.

(Continue reading)

headers

Michael Hart | 2 Feb 04:01

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

>> 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
>
> External clients should not beware of the internals, thus they can  
> only
> access the overall behavior of the aggregate itself - and not any tiny
> internal behavior bits. So it's not a lot.

Sure - it's not that I was thinking the Aggregate Root would be  
performing a lot of the domain behaviour, just that it would have a  
large contract to adhere to - some of which I thought would be related  
to the Entity, and some of which would be related to the way the  
Aggregate Root (as a boundary) is used by the rest of the domain. But  
perhaps these responsibilities aren't as different as I thought.

>> Probably... although there may be behaviour that doesn't need to be
>> exposed outside of the Aggregate (and hence is not part of the
>> external contract). Responsibilities that are required by other
>> objects in the Aggregate for example,
>
> Internal behavior is provided by aggregate's internal objects: Value
> Objects and Entities.

Right - and in this case I was talking about the behaviour of the root  
Entity (Customer in the example I think) that may just be used by  
other Entities/Value Objects in the Aggregate, but that did not need

(Continue reading)