Rickard Öberg wrote: > Niklas Uhrberg wrote: > >> So this seems to be the most important question ATM. >> I simply assumed that non-root entities can have global identity, but >> this may be an error on my part! >> It's just so common to let almost everything have a global identity even >> if it's not necessary. >> > > Well, "1234567/tire/frontleft" is a global identity in a sense! The path > *is* globally unique, even though other tires on a car may have "similar > identities, such as "7890/tire/frontleft". Works, right? > > Yes, this is trivially true - global id and a locally unique id makes a global id. IMHO this is besides the point, the topic is whether non-root entities should have a global id or not. (Finding a global id has never been the problem in this discussion...)
>> In a system for transplantation each body organ would be (probably) be a >> root entity, with a global identity despite the "normal intuition" would >> be that they are an intrinsic part of me (the root). >> >> To allow a non-root to "have no owner" (i.e. not be a part of an >> aggregate) seems to be a contradiction in terms, but assuming that we >> allow it to change owners I think the technical details of >> null-assignments and the like is a different matter. >> > > Well, if "being a root" is mostly a matter of context, then there is no > problem I think. Sometimes an entity is part of an aggregate, and may be > a root or not a root, and sometimes it is not part of an aggregate, in > which case it is an "aggregate on its own", for all intents and purposes. > > To me it sounds like most of these things could be supported simply by > having an association "Association<Entity> aggregateRoot()" in Entities > that are a part of an Aggregate. Sometimes it will be null (=the entity > is a root, or is not a part of an Aggregate at all), and sometimes it > will have a root set as it is part of an Aggregate. > > Ok, this is a very interesting topic. To me, the big question is this: What are the consequences of an entity being a root entity, and are they consistent with "dynamic rootness" ? In other words, is it good or even feasible to let one and the same entity shift between being a root and non root in different contexts? Warning: The term "context" needs definition here, I'm afraid we mean different things. I think about the DDD definition and there different contexts in principle means different models. The different models in different contexts serve different purposes while their entities will be models of the same things in the real world. So they may differ little or very much... Back to the big question then. I cheat a little and copy a list of rules from http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/05/20/entities-value-objects-aggregates-and-roots.aspx which is a summary of the characteristics according to Evans. 1) The root Entity has global identity and is ultimately responsible for checking invariants 2) Entities inside the boundary have local identity, unique only within the Aggregate. 3) Nothing outside the Aggregate boundary can hold a reference to anything inside, except to the root Entity. The root Entity can hand references to the internal Entities to other objects, but they can only use them transiently (within a single method or block). 4) Only Aggregate Roots can be obtained directly with database queries. Everything else must be done through traversal. 5) Objects within the Aggregate can hold references to other Aggregate roots. 6) A delete operation must remove everything within the Aggregate boundary all at once 7) When a change to any object within the Aggregate boundary is committed, all invariants of the whole Aggregate must be satisfied. According to the discussion on almost infinite scalability we can also take into account the transactional boundaries, one transaction cannot span multiple aggregates. Examples: 1) Suppose EntityA has a reference to EntityB (different types) , if EntityB goes from root to non-root, this is illegal if it's not a part of the same aggregate. 2) If 4) is valid, repository like functionality turn on and off depending on the root status of entites. The point I'm making is that I suspect that it will be very complex for developers to combine DDD concepts and having rootness be dynamic. The point is /not/ that it would be difficult or impossible to implement. My spontaneous reaction is that it is not at all desirable, but that is just a spontaneous reaction. Elaboration and examples needed. >> I suspect that the property of being a root entity signals that it >> should /be the root of an aggregate with more than one entity in it. / >> But this will often not be the case if only roots have global identity >> and reassignment implies global identity. >> >> My conclusion now is that only root have global identity.... >> > > Even if you consider the path-approach, where the identity includes the > root identity and the local path? > > Again, the path approach doesn't change anything, it's just a way of implementing it. (Hitherto not spelled out in the discussion...) /Niklas > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > > _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
