http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660I would have three Find() methods, one which used the default fetch mode (eager or lazy), and explicit Order.FindEager(id) and Order.FindLazy(id). Then if you ever change your default loading method, any cases where it truly matters would still have nice performance. As for implementation, if you use Criteria, you could add an alias and set a fetch mode. http://ayende.com/2184/aggregates-services-and-entities#comment3http://ayende.com/2184/aggregates-services-and-entities#comment3Fri, 23 Mar 2007 20:31:12 GMTI do not believe you have better ways. You may find more complicated ways, but for the simple issue itself, it requires a simple solution. If you give a complicated solution for everything like this, you mess up the whole project. The key is to have a good compromise for distributed computing. The so-called ADM (anemic domain model) is indeed a good compromise (so is OR mapping)! DDD promises that a “rich” model can solve the problem, it cannot. The real problem is DDD’s promise. You may say that if you read DDD carefully, you would know that it does not make the promise. However, it does make the promise for unsuspected readers. http://ayende.com/2184/aggregates-services-and-entities#comment2http://ayende.com/2184/aggregates-services-and-entities#comment2Sun, 11 Mar 2007 23:24:11 GMT@Ayende, I'm not proposing the split based on performance, but on the domain itself. Order is often a very vague term and usually has different contexts in the domain depending on what 'type' of order you are talking about. By splitting Order out into the 2 types as mentioned (ridiculous names intended btw) you are making them explicit in the domain model and the names you give them to start with give a good starting point to try and give them a good name (to expand the Ubiqitous Language). You may also find that by splitting Order up in this way you may identify other types of order that exist in the domain. By doing this you start to explore and refine the domain more and it removes those damn pesky ambigious terms that keep getting thrown about. Or to put it anther way - if you are passing Order in to a method - what srt of Order is it - one with OrderLines or without? What does the method itself expect? By making it explicit you are more clearly showing the interaction of entities in the system. On the Service/Repository note - if you have more explicit types in your domain then yes, in this instance service pretty much becomes a repository - unless the service performs other duties. One example is if an order needs approving - the service 'could' have a method Approve(Order) - but as to whether that sort of responsibility resides on a service or on an OrderApproval class - I'm not sure. Using Aggregates (which is what the explicit Order types become) does blur the boundary between service and repository. I would be very interested in other peoples opinions and experiences on this. I have a keen interest in DDD but I haven't come across as many good articles and discussions on real world experiences of DDD. This is probably why your original post got so much attention :) http://ayende.com/2184/aggregates-services-and-entities#comment1http://ayende.com/2184/aggregates-services-and-entities#comment1Fri, 09 Mar 2007 12:59:42 GMT