http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Interesting post and very simliar to something I've blogged about recently: http://colinjack.blogspot.com/2007/02/domain-coordination-layer.html On my project we've successfully used a persistence ignorant domain (I'm the same Colin Jack that Oran quotes above) but even with NHibernate there are situations where the domain, or atleast domain logic, needs to access the database. I've handled this situation in two ways: 1) Accessing reference data - In some cases deep in domain logic we need to map one value to another when the mapping is in the database (legacy design). In those cases I access the database indirectly through a Registry (Fowler), makes testing a pain in the bottom and I hope to engineer the dependency out at some stage. 2) Coordination Layer - As well as a process/application layer we have a coordination layer sitting just above the domain, I discuss this in some detail here: In our case we've ot a lot of application/process layer services doing what your OrderService is doing. For example our Client class has an Accounts collection that we lazy load (NHibernate). We use repositories (Evans) and if we know that to run a particular method we're going to use every Account in the Client collection then we'll use an eager fetching query when getting the Client to ensure we get all its Accounts too. Up till now that sort of logic has been in the application layer but the more I think about it the more I think our domain coordination layer might be the place for it, if so we'll move our equivalents of your services into it. On the more general issue of whether our domain should access repositories...in my experience no. The minute your domains getting involved in repositories, dependency injection etc etc your making testing hard. It also makes the domain harder to understand which in my view is the best argument against it. Anyway good post. http://ayende.com/2145/entities-services-and-what-goes-between-them#comment55http://ayende.com/2145/entities-services-and-what-goes-between-them#comment55Sat, 31 Mar 2007 17:36:42 GMTI was reading an blog entry by Ayende Rahien (aka Oren Eini) again, " Entities, Services and what goes http://ayende.com/2145/entities-services-and-what-goes-between-them#comment54http://ayende.com/2145/entities-services-and-what-goes-between-them#comment54Sat, 31 Mar 2007 00:39:34 GMT@Stephen Great addition to the discussion. I think your comment explains what I tried to say with "A tight connection with the problem domain at hand makes giving good examples for explaining Domain-Driven Design so hard". Without the proper context, and thus variations on the language results in a confusing discussion in one where all participants seem to have a different mental model of the problem at hand which results in different solutions. http://ayende.com/2145/entities-services-and-what-goes-between-them#comment53http://ayende.com/2145/entities-services-and-what-goes-between-them#comment53Sat, 10 Mar 2007 21:13:08 GMTThis is related to Paul Gielens thread above as well (where to put the comments?). If you only have a very few use cases which need to calculate cost then would this effectively be a different 'type' of Order? This is where the aggregates help out as they define your boundary. From the above example Order seems to have an OrderLine property. If this is correct then does this mean that in some cases Order could have OrderLines and in some cases it doesn't? Maybe Order is too vague at this point - if you have an instance of Order, what 'type' of order is it? If you use aggregates then those become your 'types' of Order in the domain and makes them explicit. The repositories are then used to retrieve and store the object graph of the aggregates. If you have defined aggregates then the CalculatedOrderService would return a CalculatedOrder which has a CalculateCost method. There could then also be a DoesntHaveOrderLinesOrder type of order. As for Order, that could be abstract now as both CalculatedOrder and DoesntHaveOrderLines could inherit from it. I know the names need work - but if you do have multiple types of Order then maybe order is too ambiguous a term. Having names obviously badly worded names like this does at least create discussion about what terms to use instead which works towards extracting and defining the Ubiquitous Language. Given that you have the knowledge of the domain itself - are there effectively multiple types of Order - one with OrderLines (and the calculation of those order lines) and once without? What is the case for having one Order type in the domain? http://ayende.com/2145/entities-services-and-what-goes-between-them#comment52http://ayende.com/2145/entities-services-and-what-goes-between-them#comment52Thu, 08 Mar 2007 09:57:47 GMT@Stephen, How would the order service know that it needs to load the order lines as well? http://ayende.com/2145/entities-services-and-what-goes-between-them#comment51http://ayende.com/2145/entities-services-and-what-goes-between-them#comment51Thu, 08 Mar 2007 06:06:08 GMT@Ayende: In the OrderService with the CalculateCostForOrder method, I would have leaned towards the service having a GetOrder(orderid) method which returned the order, and for the client to then call order.CalculateCost() (so client would call money = orderService.GetOrder(orderId).CalculateCost(). Now you can add more responsibilities to the entity without having to make the service aware of them. I'm interested as to what is gained by making the service aware of the orders responsibilities? http://ayende.com/2145/entities-services-and-what-goes-between-them#comment50http://ayende.com/2145/entities-services-and-what-goes-between-them#comment50Wed, 07 Mar 2007 13:54:35 GMTAyende’s example calculates the cost for an order. For this it needs the order lines associated with http://ayende.com/2145/entities-services-and-what-goes-between-them#comment49http://ayende.com/2145/entities-services-and-what-goes-between-them#comment49Wed, 07 Mar 2007 10:16:21 GMTA while ago I dug into this same debate on the DDD mailing list. What I found is that there are basically two camps under the DDD umbrella. Camp 1: The domain model shouldn't care about persistence Camp 2: Clients of the domain model shouldn't care about persistence Eric Evans leans more toward camp 1 (as do I), but camp 2 appears to be louder. Here are a couple Eric Evans quotes on the subject: "My opinion is that it is reasonable to choose an architecture that does not allow entities to talk to repositories." http://tech.groups.yahoo.com/group/domaindrivendesign/message/4749 "Generally, I do not like model objects to reference repositories, so my answer would be, generally, the client. The client might look it up based on a well-known name, or you might use dependency injection. "In effect, the repositories form a layer just above the model objects. They obviously must be above the model objects since their primary purpose is to obtain references to those objects and pass them to requestors. It would not be obvious that they would be above *all* model objects (rather than just above their own), but I find it works better. Repositories are edging into application functionality rather than model. You could view them as service access to the model objects." http://tech.groups.yahoo.com/group/domaindrivendesign/message/2305 And another quote from Colin Jack on the DDD mailing list: "Personally I don't like accessing repositories from the domain as I find all the setup needed to mock them out during testing is just a pain in the neck and makes maintaining my unit tests very difficult, but a lot of people seem to access them from the domain." http://tech.groups.yahoo.com/group/domaindrivendesign/message/4761 http://ayende.com/2145/entities-services-and-what-goes-between-them#comment48http://ayende.com/2145/entities-services-and-what-goes-between-them#comment48Tue, 06 Mar 2007 20:21:10 GMTOren, Great post, awsome comment thread. I've put up a post showing a design that takes out the fetching strategy from the service objects and puts it into the generic repository. [http://udidahan.weblogs.us/archives/389](http://udidahan.weblogs.us/archives/389)http://ayende.com/2145/entities-services-and-what-goes-between-them#comment47http://ayende.com/2145/entities-services-and-what-goes-between-them#comment47Tue, 06 Mar 2007 15:05:28 GMTRead my followup here (somehow trackbacks don't work): http://harald.fluffnstuff.org/serendipity/archives/50-The-Right-Architecture-for-Your-Application.html http://ayende.com/2145/entities-services-and-what-goes-between-them#comment46http://ayende.com/2145/entities-services-and-what-goes-between-them#comment46Fri, 02 Mar 2007 08:55:14 GMT@Andrew, The other approach, I feel, gives too much responsibilities to the domain objects. They are still testable, but I feel that this makes the significantly more complex. I am placing the repository calls in both services and controllers at the moment. http://ayende.com/2145/entities-services-and-what-goes-between-them#comment45http://ayende.com/2145/entities-services-and-what-goes-between-them#comment45Thu, 01 Mar 2007 08:46:38 GMT@Ayende, I'm handling it the same way, but i have some doubts about where to put DAO (or Repository) calls? I can do it like you showed above, add service layer and place all calls there, but i also can inject my DAOs directly in domain objects, making service layer is needless (and still keeping domain objects testable). I just can't decide, probably because of lack of experience. I know you prefer services, but what you think about second approach? :) http://ayende.com/2145/entities-services-and-what-goes-between-them#comment44http://ayende.com/2145/entities-services-and-what-goes-between-them#comment44Thu, 01 Mar 2007 08:43:47 GMT@Andrew, I don't see any issue with your English. The way I handle such scenarios is by having the service know what to load, and then calling the entity to do the real business. http://ayende.com/2145/entities-services-and-what-goes-between-them#comment43http://ayende.com/2145/entities-services-and-what-goes-between-them#comment43Wed, 28 Feb 2007 18:24:37 GMTI found this article http://ricbrown.blogspot.com/2004/09/transparent-persistence-paradox.html. Looks like problem described there is the same as Mike described. Sometimes there are cases when domain model needs to hit the database, or else solution will have scalability problems. What if your domain object needs to perform some business actions on dependent child collection (say, calculate total amount of all payments for certain period), but collection loading makes big performance impact? This is a business rule and should be placed in domain model, but what about performance in that case? Ayende, how do you handle situations like this? P.S. Sorry for my English :) http://ayende.com/2145/entities-services-and-what-goes-between-them#comment42http://ayende.com/2145/entities-services-and-what-goes-between-them#comment42Wed, 28 Feb 2007 18:16:42 GMTNo, the injection usually is not to the entity, but to the repository itself. http://ayende.com/2145/entities-services-and-what-goes-between-them#comment41http://ayende.com/2145/entities-services-and-what-goes-between-them#comment41Wed, 28 Feb 2007 16:13:36 GMT@Christopher Thanks, I'll check that out. I know generally about dependency injection, but doesn't that still make it so the entities have a connection to the repository, just that this connection is created by some outside object, and set on the entities by this outside object? http://ayende.com/2145/entities-services-and-what-goes-between-them#comment40http://ayende.com/2145/entities-services-and-what-goes-between-them#comment40Wed, 28 Feb 2007 15:56:13 GMTI see a lot of confusion arising merely by the choice of words. My understanding for Entity, Service, Unit of Work, et cetera is reflected in this: http://www.martinfowler.com/bliki/EvansClassification.html (and related books from the DDD camp). @Mike, Ayende's article (http://msdn2.microsoft.com/en-us/library/aa973811.aspx) addresses the question of security context (aside from being a great practical example of IoC/DI). http://ayende.com/2145/entities-services-and-what-goes-between-them#comment39http://ayende.com/2145/entities-services-and-what-goes-between-them#comment39Wed, 28 Feb 2007 14:42:37 GMT@Mike, There are several ways to handle it. The simplest one would be with: [Security.OnlyAllowUsersThatHaveXYZ] public virtual void AddOrderItem() {} And then either build a proxy that would intercept that call ( AOP ), leaving the entity blissfully unaware of the requirements. Or check this when the user attempts to save to persistent storage. I found that placing all my security checks inside the "is valid to save" freed quite a bit of my time, and made sure that I would not forget about it. Another option is to inject a service into the entity, but that is something that I would like to avoid if possible. http://ayende.com/2145/entities-services-and-what-goes-between-them#comment38http://ayende.com/2145/entities-services-and-what-goes-between-them#comment38Wed, 28 Feb 2007 07:27:40 GMT@Shawn, I threat them the same way. Getting something from the database is something that I never think about, no more than I think about opening a transaction. "something" handles it, but I don't really care what. It is completely infrastructure issue as far as I am concerned. http://ayende.com/2145/entities-services-and-what-goes-between-them#comment37http://ayende.com/2145/entities-services-and-what-goes-between-them#comment37Wed, 28 Feb 2007 07:20:05 GMT@Ayende order.AddOrderItem(item) may break some business rule, where for example the OrderItem added isn't allowed to be added by the particular user that is trying to add it. I know this is a strange example, but it could require security checks for that user that require a database hit. into some security tables. I suppose you could preload the Order (or OrderItem) with the security data necessary for that particular user, but what if the security rights change while the Order is in memory? In the framework we have built at our company, we use these disconnected entities, and they generally work fine, except for when business rules depend on data not relationally related to the entities themselves (like security). http://ayende.com/2145/entities-services-and-what-goes-between-them#comment36http://ayende.com/2145/entities-services-and-what-goes-between-them#comment36Wed, 28 Feb 2007 06:13:09 GMTI'm curious why you use the term "infrastructure logic" to describe classes that might otherwise be abstracted as Data Access Objects. It seems to confuse the purpose with other types of infrastructure such as transactions, remoting, etc. http://ayende.com/2145/entities-services-and-what-goes-between-them#comment35http://ayende.com/2145/entities-services-and-what-goes-between-them#comment35Wed, 28 Feb 2007 01:27:30 GMT@Anatoly, 1/ you call it an entity, I would call it a root / aggregate entity, but the meaning is the same. The main difference as far as I can see is that I can ask questions on entities, but not on non-entities. Non entities are always (maybe implicitly) qualified by an entity. 2/ UserProfile is an entity in my book, I may ask it questions and it participate in business logic. Usually with regard to either personalization or security, which are often treated as infrastructure concerns, but I would still regard it as an entity that takes part in the domain. Just to give an example, the logic for whatever I am allowed to do an operation in an HR application is certainly something that involves business logic, and that is something that the UserProfile (not actually named that, but the same idea) is responsible for. 3/ I think that I agree with you on this, although I call them services or controllers NewOrderController, ProcessBillingService which means that the semantics of using them is different. 4/ I mentioned logging as part of the infrastructure services, not a business concern in most cases. Although since it is a cross cutting concern, it is a bit different than most other things in the application. http://ayende.com/2145/entities-services-and-what-goes-between-them#comment34http://ayende.com/2145/entities-services-and-what-goes-between-them#comment34Tue, 27 Feb 2007 20:12:47 GMTOren, I just see it like so: 1) Order is entity (OrderEntity) that consist of several objects: Order, OrderItem, etc. OrderItem cannot exist on its own. 2) UserProfile is not Entity. ("UserProfile" may be Customer, whatever - somebody who logins to the application and has preferences - is not Entity) 3) BusinessLogic - Sematincs is all that makes a difference :) The main rule - names should follow use cases. (It should be in english like ProcessOrder, PaintGrass :) whatever) 4) Loggign - you mentioned LoggingService - I say that Loggign is not a part of application. >> Views - responsible for converting the data from the >> controller into something that the consumer can understand. I don't understand what views mean. If you need to translate your objects - menas to me that you rather build them incorrectly - I don't translate my classes to user interface :) either in web nor in win apps. Anyway - good post, interesting discussion. http://ayende.com/2145/entities-services-and-what-goes-between-them#comment33http://ayende.com/2145/entities-services-and-what-goes-between-them#comment33Tue, 27 Feb 2007 19:19:29 GMT@Anatoly, 1/ One entity is one object, the way I am doing it. It may not be usable by itself, but it is a valid entity. To take for example OrderLine, it is an entity, but fairly useless without its Order. Maybe you are refering to root/aggerated entities? 2/ UserPfofile - I don't think that I follow what you meant here. 3/ What you call "application classes" I call services or controllers, depending on the level of sophistication. The semantics are slightly different in this regard, but I believe that we are in agreement here. 4/ How does logging relates here?? http://ayende.com/2145/entities-services-and-what-goes-between-them#comment32http://ayende.com/2145/entities-services-and-what-goes-between-them#comment32Tue, 27 Feb 2007 19:06:58 GMT@Ahmad, Yes, simple CRUD would generally be forwarded to the repository. If code gen is an issue, there is no reason that you can't generate the service as well. Personally, I don't like code gen that much, and would much rather build as needed rather than spent more time building the generator than the app, which was my impression where a lot of the ambitious projects went. I do generate some stuff, but that is usually stuff that is build from the object model of the application. http://ayende.com/2145/entities-services-and-what-goes-between-them#comment31http://ayende.com/2145/entities-services-and-what-goes-between-them#comment31Tue, 27 Feb 2007 18:56:21 GMT@Gustavo, Yes, what I am talking about contradict the Active Record model. In general, I _really_ like the way AR can infer everything for me, and take away much of boring details of working with NHibernate. That said, my personal belief is that a repository driven approach is a more flexible way to handle the issue. I keep the power of AR, but I can now operate at much greater flexibility, see my article on MSDN to see some of the things that I can do with repositories. http://ayende.com/2145/entities-services-and-what-goes-between-them#comment30http://ayende.com/2145/entities-services-and-what-goes-between-them#comment30Tue, 27 Feb 2007 18:48:41 GMTsome points I can think about: 1) One entity can be (usually) several objects 2) UserProfile (customer/user, etc) - separate thing 3) "Application" (Business Logic) classes should translate application use cases: for example: ProcessBilling.cs, PlaceOrder.cs, etc. 4) Logging = infrastructure, is not a part of the application in any way. http://ayende.com/2145/entities-services-and-what-goes-between-them#comment29http://ayende.com/2145/entities-services-and-what-goes-between-them#comment29Tue, 27 Feb 2007 18:48:21 GMT@Mike, Order would definitely have a method called Order.AddOrderItem(); which would be something like: public void AddOrderItem(Item item) { Items.Add(item); item.Order =this; } Persisting this assoication is the responsibility of NHibernate, not of the entity. This is part of the fun of working with a Unit Of Work. Just to clarify, my entities are certainly part of the domain. Although I get the feeling that you and I are talking about different things when we discuss what the domain is. About business logic that needs talking to the database. I would strive very hard to avoid doing it. Entities validate business logic by traversing the object graph they have, not by calling to the database. Calling to the database makes it a lot harder to just start a new entity and run business logic. http://ayende.com/2145/entities-services-and-what-goes-between-them#comment28http://ayende.com/2145/entities-services-and-what-goes-between-them#comment28Tue, 27 Feb 2007 18:42:31 GMTEntities and Services http://ayende.com/2145/entities-services-and-what-goes-between-them#comment27http://ayende.com/2145/entities-services-and-what-goes-between-them#comment27Tue, 27 Feb 2007 17:41:31 GMTAyende, In that case for simple CRUD operations that contain no business logic or validation, the service method becomes a pass through to the repository. If these methods were on my entities, atleast I could use code gen for creating them. http://ayende.com/2145/entities-services-and-what-goes-between-them#comment26http://ayende.com/2145/entities-services-and-what-goes-between-them#comment26Tue, 27 Feb 2007 16:51:35 GMT