On Sat, Jun 2, 2012 at 2:47 AM, Tibor Mlynarik <[email protected]> wrote: >> * Entities are bound to an Aggregate > > how are bound ?
I mean all Entities "belong" to an Aggregate, even if the entity is completely stand alone, it is then a "Standalone Aggregate". If you read Vaughn Vernon's papers (soon book) on the subject, I think you get the point. > Is Aggregate new type of Composite or Aggregate = AggregateRootEntity No. An Entity created without a reference to an Aggregate Root is an Aggregate Root, otherwise not. (I have not yet figured out the actual API for this, whether it is in the Module (maybe), Entity (possibly) or Association (probably not). > And the same Entity type can be once AggregateRoot and once local entity? Once an Entity is created as "Aggregated", i.e. part of cluster of Entities with an Aggregate Root, it can't be an Aggregate Root itself. It is only a two level structure, exclusive in nature. You can still have an Entity referencing another Aggregate (via the Aggregate Root), but typically "others" should not know about any internals of the Aggregate. All commands (CQRS if you like) are defined in the Aggregate Root entity. In case an Entity is to "move" from one Aggregate to another, this must happen via Values, not to violate the boundaries. The DDD folks are trying to accomplish all this with "discipline", but it turns out to be very hard and it quickly collapses without any enforcement mechanisms. And that is where Qi4j has a unique position. Since we control the "method invocation stack", we can actually enforce a lot of these 'rules'. > (I am just thinking how to best prepare my codebase to changes. ) IF we do this, the main thing to think about is your Consistency boundary. Again, if you read Vaughn's papers, you will notice that we often introduce Invariants to aggregates that are purely technical, without corresponding concept in the business world. Sometimes business will not even recognize that the seemingly sensible invariant, is actually not a business requirement. Greg Young has in his training some rather interesting cases around "eventual consistency" and "invariants" where the business requirements are actually at odds with technical implementation details, the way we normally do things. For instance; He brings up a race condition between two customers trying to buy the same boat. From a technical perspective, we would work hard to ensure that both are not told that they got the boat, and we will reject the second customer. Business however (according to Greg) is likely to rather have both be accepted, but INFORMED that there are two buyers and work out in the "business/human world" how to resolve it. Phone calls, negotiation, price adjustments, sell another similar boat and so forth are completely valid business actions, which we try to prevent with ACID. >> * Invariants are declared on the Aggregate Root or assigned to the >> Aggregate Root at assembly. > > So Invariant is something like more complex Constraint applied before > complete/save ? Correct. Constraints are for method invocations. We have also discussed the possibility to have Constraints on return values, and that may come. Invariants are to ensure that the entire Aggregate is in a valid state, and if not, reject the creation/update. Classic example is "Ensure order value + customer outstanding credit does not exceed customer's credit limit.". Here a good designer would spot another "requirement leak"; "What if the customer's credit limit is lowered after the order is saved?". We software folks can not answer that, we can only ask business. Answers could be; "The credit limit is established when the order is created. We also need the ability to override the credit limit for an individual order..." or "If the credit limit is lowered and the customer's credit is higher, then no more orders should be allowed until the outstanding credit has dropped below half of the new credit limit" (My dad had such rule, since lowering credit limit was only done to customers that started to fail payments, and likely to go bust.) I am trying to exemplify that business has all kinds of clever ways to deal with race conditions, invariant breaks and other business rules. WE should ASK and have the tools to fulfill their requests. Btw, if you have a chance to take Greg's course; Highly Recommended!! (Even for Rickard! ;-) ) Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/6a2pl4j I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
