Re: Re: Populating new aggregates

I'm not sure we are on the same page what constitutes an aggregate. To me an aggregate is a boundary around entities/value objects which is persisted as a whole.
 Therefore your validation logic and any other rule should be satisfied only within one aggregate.
 

 I have other concepts for objects consisting from multiple aggregates.
 Although there is one exception to that rule and that is when I save a snapshot version of the aggregate alongside other aggregate, for example model such as
 

     aggregate Customer { 
       string name; 
     }
     aggregate Invoice { 
       date date; 
       Customer *customer { snapshot; }
       List<Item> items; 
     }
     entity Item { 
       int quantity; 
       money price; 
     }
 

 could be considered that Invoice consists from multiple aggregates, but there is clear separation of persistence (* = reference to another aggregate) - and usually this means lazy load, although in this case also means - save/load a snapshot of the customer, not the latest version.
 

 

 

---In [email protected], <xenoterracide@...> wrote :

 I agree that aggregate should be fully populated, but it's often useful to have only a projection of the aggregate. Problem is that people dislike adding a new specialized type and instead try to reuse existing one. My solution was to make it cheap to create a snowflake out of aggregate and thus improve the domain instead of trying and shoehorning it into an existing aggregate.
  
 I agree in theory, but in practice there are two situations I can think of off the top of my head that  fully prepopulating the object graph doesn't work.
 

 1. Any model that allows you to save your work as a draft, this means that you need to be able to save the work as incomplete. You might be able to save all the fields in this case, but they might not be valid.
 

 2. Your aggregate might actually be multiple aggregate roots, take a User and a Role, both are Aggregates, you may have one without the other. People often, mistakenly, model it as User->Role instead of User->Roles->Permissions, thus may think of Roles as being part of the User aggregate. It is easy with Data Mappers to code either of these with just references so you can navigate them, again making them deceptively one aggregate. Of course an aggregate can contain another aggregate, so this is not wrong, however it leads you to think that the object graph should be complete, and it is according to aggregate boundaries you may not have recognized.
 



 -- 

 Caleb Cushing 

 http://xenoterracide.com http://xenoterracide.com