Hi, While I'm porting dddsample model to qi4j, I'm beginning to wonder whether we should separate domain modelling and persistence modelling.
----------------------------------- 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? 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". 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. If we're to implement DeliveryHistory as: o Entity - How do I declare Cargo#deliveryHistory as Immutable association? - How do I automatically create DeliveryHistory entity and associate it with Cargo? o Composite - Should we support persisting ValueObject with associations? - How do I automatically create DeliveryHistory composite and set it to Cargo? --------------------------- If we separate them. We would be able to retain all the dddsample API, and all that constants. UNKNOWN_LOCATION etcs. Would not be a headache, as we can just represent them as null in persistence. Which approach should I take? Combine or separate them? Regards, Edward Yakop _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
