Re: Understanding Agrregates

Ah, "UML definitions" explains a lot of confusion when reading your posts. 

 I was referring to an account shared by a single customer and a single product. If I understand your terminology correctly this would fall under multiple composition - which implies it's referenced from two different aggregate roots/entities. And since aggregate boundary is broken if two aggregate roots share same entity instance this looks like a no-no, which leaves only an option for association to be an aggregate root.
 

 Are you saying that entity/value object is a design decision, not a model requirement? That looks wrong if I'm interpreting you correctly.
 

 Ok, I think I understand your terminology (UML) now, but then disagree on the guidelines that identity on it's own (not depending on someone else identity) is good enough reason to differentiate entities/aggregate roots.
 

 From my perspective primary difference between entities and roots is whether you want/can save them as a whole.
 

 So for example:
 

 entity Account(id) { string id; }
 aggregate Customer {
   List<Account> *accounts;
 }
 

 looks like a valid model which is using composition, but accounts are identified on their own.
 Of course, this "breaks" (at least on one level) the navigate to the entity though the aggregate DDD guideline, but then again, I think that guideline is at least "suspicious".
 

 Regards,
 Rikard