Hey, Excellent questions!
Edward Yakop wrote: > While I'm porting dddsample model to qi4j, I'm beginning to wonder > whether we should > separate domain modelling and persistence modelling. YES! I am actually in a separate discussion group, along with Coplien and Venners and others, where we are discussing that objects have two parts to them: their internal interface and then the roles they play. The roles they play are entirely dependent on context, because it is the context(/client) that determines them. If you shift your terminology so that "persistence modeling"->"object modeling" and then "domain modeling"->"role modeling", then I think that's the key. Once you are in this mindset you realize that the ONLY way to interact with an object is through the roles, which then map client calls to the internal state, where the domain methods are. In short: model the object as *it* wants to view itself, and then for each context/client/usecase create interfaces for how it would want the objects to look like. Then implement these interfaces in the object and map them to the internal object definition. Makes sense? > ----------------------------------- > If we're to combine them > > Use case 1: > Cargo#changeDestination( Location ) -> Cargo#destination().set( location ) > Cargo#attachItenary( Itenary ) -> Cargo#itenary().set( itenary ) > >>From cargo user point of view, this is probably still acceptable. > But, don't we expose unnecessary stuff. E.g. Location is an > association, it's meta data etcs? > Should Cargo user even need to know that location is an association? No, you are right. Destination and itinerary are internal. You would have something like CargoRole#changeDestination() -> Cargo#destination.set(), where Cargo is a private mixin. > Use case 2: > Cargo#detachItenary() -> Cargo#itenary().cargo().set( null ), itenary > = Cargo#itenary().get(), Cargo#itenary().set( null ), > unitOfWork.remove( itenary ) > For now, we would need to create an abstract Association class that > can easily override by qi4j user. > Later on, we need to revisit "cascade". For lifecycle cascading there is actually Lifecycle.create/remove for this stuff. In Lifecycle.remove you would call remove on all "owned" entities in an aggregate, so that if you do remove on the top-level aggregate you will know that everything in it is removed appropriately. > Use case 3: > Cargo#deliveryHistory() > In ddd sample, DeliveryHistory is a place holder for cargo events. > No database table is representing DeliveryHistory and > Delivery history is immutable. Sounds like a Query to me! /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
