http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660This should go to the castle mailing list http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment19http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment19Thu, 13 Aug 2009 03:29:38 GMTAyende, (as you are officially known to master Castle MK/Windsor ;), could you point or elaborate on how Event Registration Facility may help to wire such design without friction? I've not used it yet but thinking of triggering all components satisfying IEventHappeningListener <tevent,> seems interresting. But there are some rules to think about such as ordering of the handlers, being atomic or compounded, etc. So this look like a tricky issue when dealing with larger than sample code but still my aim for "project+1", just because the provided decoupling is great for evolutivity/maintability http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment18http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment18Thu, 13 Aug 2009 02:33:20 GMTTim, The difference between having a smart persistence model and a domain model are quite large. It is more related to structuring of the application and the code than just how you handle persistence. http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment17http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment17Sat, 08 Aug 2009 13:55:37 GMTJohn, No problem man just a "small overreaction" :-) Santos http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment16http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment16Fri, 07 Aug 2009 02:30:03 GMTSantos, I didn't mean to offend anyone. I thought u might have missed it and just pointed it out. chill out man ;) http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment15http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment15Thu, 06 Aug 2009 23:19:03 GMTWell, "John" in that case I was responding to Oren and I do not need a translator! Thanks, Santos http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment14http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment14Thu, 06 Aug 2009 18:09:48 GMTI think Erik has clearly mentioned above the difference between Specification and Domain Event: "Specification-- Does something Meet some criteria Domain Event- Something Interesting Happened." http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment13http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment13Thu, 06 Aug 2009 05:24:14 GMTOren, Specifications have worked fine for me but I don't know too much about Domain Events yet. As I as said in my first post I just wonder how much better it is than using Specifications. As soon as I have a chance I'll give it a try. For now I just take your word for it. Santos http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment12http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment12Thu, 06 Aug 2009 04:59:32 GMTWhile I agree with all of your article, still DDD is not the only way to go. My only point is while for DB apps : DDD is great for managing complexity, still there are other cases to not use DDD. http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment11http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment11Tue, 04 Aug 2009 08:54:14 GMTI often hear that you should only use the domain model pattern for complex scenarios. What is a good pattern for the "simple" cases? How do you know if you have a domain model or just a persistant object model? I find encapsulating business rules in "domain" objects to be beneficial even in simple cases. Am I missing something here? http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment10http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment10Tue, 04 Aug 2009 07:49:45 GMTSantos, As Erik pointed out, this is not something that can track state changes, which is what we are interested in here. Second, this means that now you have to _manage_ specifications, that is ugly. I don't want to have lots of if statements all of over the place. Domain events make all of that complexity just go away http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment9http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment9Tue, 04 Aug 2009 06:10:00 GMTAyende, Yeah the thing I really like about it is that it allows you to be much more OCP with your Domain Model and services while still adding Interesting behavior to Domain Event Handlers. The number of reasons for both your service class and Domain classes to change just reduced considerably when you follow his guidance in the article. This coupled with the way he does different models for different bounded contexts (or no model at all in some bounded contexts if it is not justified) likely reduces the urge to move domain behavior out of your models. Erik http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment8http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment8Mon, 03 Aug 2009 18:45:51 GMTOren, In that case you could encapsulate all the other predicates in the IsSatisfiedBy in a more general/composite specification. But usually those conditions are within the Aggregate or are accessible from the specification. If there is a better way I am open to use it! Santos http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment7http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment7Mon, 03 Aug 2009 18:40:18 GMTSantos, That looks _really_ bad. Imagine that we have 10 such conditions. Are you going to have 10 if statements? Or would you rather have it in the a more loosely coupled way? http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment6http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment6Mon, 03 Aug 2009 18:16:42 GMTWow, I really should proofread prior to hitting submit especially if typing while having another conversation. Corrections: send the customer an email every time they submit an order assume that there criteria, but meet some criteria? ----All the really weird capitalization Erik http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment5http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment5Mon, 03 Aug 2009 17:32:40 GMTThat would send the customer an order every time they submit an Order. Not just when they become preferred. Also, Assume that their are multiple ways that a customer may become preferred. The specification may tell you if a customer meets some criteria. But it won't tell you when that customer change happened. Specification-- Does something Meet some criteria Domain Event- Something Interesting Happened. Usages If (Specification.IsSatisfiedBy(something)) Do Something Whenever (Something Interesting Happens) Do Something (1.Log it happened,2Publish It happened on a bus,3, Let some other object know it happened, etc...) The two are Orthogonal IMO. http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment4http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment4Mon, 03 Aug 2009 17:27:33 GMTWell, one way to do it, of the top of my mind: public class OrderService { IOrderRepository mRepository; IMailService mMailService public OrderService(IOrderRepository repository, IMailService mailService) { if(repository == null) throw new ... if(mailService==null) throw new ... mRepository = repository; mMailService = mailService; } public void Submit(IOrder order) { order = mRepository.AddNew(order); if(order.PreferredSpecification.IsSatisfiedBy(order)) mMailService.SendMail(order.Customer) } } public class OrderPreferredSpecification : Specification <order { public override bool IsSatisfiedBy(Order order) { // Build your predicates here and return true/false } } public class Order { //...Other properties public PreferredSpecification { get; } } > BTW in regards to EF he could have used ORM then! Santos http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment3http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment3Mon, 03 Aug 2009 16:10:55 GMTSpecifications ?? How could you do the following from the article with specifications? I am not really seeing the connection? public class CustomerBecamePreferredHandler : Handles <customerbecamepreferred { public void Handle(CustomerBecamePreferred args) { // send email to args.Customer } } Also, the only reference to the EF is a picture where your choice of ORM is really a peripheral matter. Was there somthing else? >http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment2http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment2Mon, 03 Aug 2009 14:53:41 GMTI liked the article and I like the idea of domain events but I wonder how much better it is than using DDD Specifications. IMO if you submit the aggregate for persistence and apply the Specification to the returned persisted one it will work exactly the same. Anyway they are to separate concerns. Also I have some questions about the second part of the article. It looks to me like a kiss in the EF ass. :-) Santos http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment1http://ayende.com/4095/your-domain-model-isn-t-in-the-entity-relationship-diagram#comment1Mon, 03 Aug 2009 03:29:51 GMT