On 2009-11-16 12.41, Niclas Hedhman wrote:
Rickard's conclusion is pretty much that a lot less "services" are to used compared to the OOP/POJO world, where behavior-free containers are tossed at services to be manipulated, and instead things are handled at each object. So, for instance, Manager may have 'promoteEmployee( Employee employee ) in which case it will list that employee in "ManyAssociation<Employee> managedResources()", perhaps communicate this to some HR Manager and so forth. Think real life! :-) It is not the object that decide what Role it current has, it is the context the object is in that dictates it, even in this example.
Yes, pretty much all the domain logic resides in the domain objects themselves. I have NO application services right now that does domain logic. However, thinking about it, what will happen in the DCI context is that I'll get Context objects (fly-weight, not singleton like services), that will drive the interactions in the domain model.
If you look at the CQSR movement on the DDD-mailing list, the trend is that the domain model ONLY deals with writes, i.e. commands. The reading is done through a thin DTO-layer, straight to the persistence mechanism. This allows you to use denormalized views, and makes it easier to uses non-RDBMS too I think. When your domain only handles commands, many of the aspects you'd normally consider (for purposes of reading) go away.
/Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
