On Thu, Oct 23, 2008 at 9:04 AM, Rickard Öberg <[EMAIL PROTECTED]> wrote:
> 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. Cool. Me likes. > 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. And we have the 'answer' to the "Getters are Evil!" debate that has been brought up the last couple of years. > 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. So, in practical terms; We should view the Context from a behavioural model, where we effectively use Composite interfaces with backing NoopMixin and the 'map' to internal state happening in Concerns?? >> 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! Not necessary. Having an EventHistory for an object can make sense, without being query or queryable. Depends on what the use-cases really are. In this case, I think it is used to pull up the "path to customer" view (like UPS/FedEx has as the default view for a TrackingNumber), and no reason to have that being assembled by a relatively expensive Query. Cheers Niclas _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
