Ayende @ Rahien

Joe Brach commented on Avoid externalizing decisions from your domain model

Sat, 13 Jun 2009 21:45:13 GMT

Use service(s) objects that do something for you instead being something. Eventually this business question is going to get complicated and the user is going to want to see the broken rules etc.. the service will be able to provide the information without mucking up your domain. public class CanBePutInIsolationService: IService { public CanBePutInIsolationService( Prisoner prisoner) {} . ..... .... .}

Marco commented on Avoid externalizing decisions from your domain model

Wed, 10 Jun 2009 12:43:05 GMT

I would utilize the specificaiton pattern for this scenario. encapsulate it away in the business layer.

Steve commented on Avoid externalizing decisions from your domain model

Wed, 10 Jun 2009 11:37:17 GMT

I see a strategy pattern developing - we have the domain object and a set of behaviors associated to that domain object. +1 on the specification pattern suggested above. Personally I like Ritesh Rao's blog post on the subjects of validation/business rules: [www.codeinsanity.com/.../...tion-and-business.html](http://www.codeinsanity.com/2008/12/framework-for-validation-and-business.html) "developing implementations of Validation and Business Rules logic in your applications, using Expressions and Specifications as light weight rule evaluators."

Hendry Luk commented on Avoid externalizing decisions from your domain model

Wed, 10 Jun 2009 11:20:33 GMT

I think ViewModel/DTO is definitely needed and there's no question about it. But the problem in question is more on where to place the logic to acquire that information in the first place before we can even provide it to ViewModel. Anyway, IMO these specifications are validating the eligibility of certain actions. So it should live whereever the action takes place.... Hence, if SendToIsolation is a domain operation, then by all mean, IsEligibleForVacations should live there, or somewhere else within reach. (This knocks presentation and app layers off the list)

JC commented on Avoid externalizing decisions from your domain model

Wed, 10 Jun 2009 06:02:14 GMT

@Brad - [www.balsamiq.com](http://www.balsamiq.com)

Brad commented on Avoid externalizing decisions from your domain model

Wed, 10 Jun 2009 05:06:11 GMT

Off topic: What tool do you use to draw your diagram?

Mike G commented on Avoid externalizing decisions from your domain model

Wed, 10 Jun 2009 01:15:23 GMT

I think this shows an example of why the separation between the presentation and domain makes things a lot harder than they should be. In my mind, the presentation is part of the domain, at least the part of the presentation which is supposed to show data. If I build a banking application, a "Total Amount in Account" is shown in the presentation because it is an important piece of information for somebody interested in the "banking domain". In this sense, the presentation is driven by the domain (the total amount in an account must be accessible from the domain model) and the domain is driven by the presentation (this is a piece of information a user will want to view, so the domain must know how to handle it). Naturally, this is a two-way relationship, so I don't see a reason to separate this functionality into two separate layers. Now, if you are talking about the code that actually puts this data onto the screen, I consider that a presentation concern which should be separate. But if you are just talking about being concerned about putting properties that are only meant to be viewed (and not part of some other domain calculation) in the "domain layer", I say that this I something that should be in the domain layer. The only thing that should be in the presentation layer should be logic which knows how to put data onto the screen...what goes on the screen (ie what is important to the user of your prisoner domain) and how this is calculated is a natural part of the domain layer. Mike

Neil Mosafi commented on Avoid externalizing decisions from your domain model

Wed, 10 Jun 2009 00:33:36 GMT

Have to say that the specification (or query object) pattern makes the most sense here. Why? Having the IsEligibleForVacations property (with lots of business logic) on the domain model means you can't query your domain propertly. It means, for example, you can't ask it to give you all prisoners who are eligible for vacations, without doing a massive in-memory filter of all prisoners (not ideal!). The domain model should not assume how the application wants to use it.

Tyler commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 22:33:28 GMT

I think that all of those things ARE domain logic. They are pieces of information about a prisoner, rather than information on HOW to display a prisoner. I would make those methods properties, though, and have them calculated early. If you still want those properties separated from the Prisoner class, make a one-to-one class off of Prisoner called PrisonerVacationRequestEligibility and put them there. I'd still have them calculated early, though. This way they are easily discoverably, simple to understand and explain, and very performant.

Joe K commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 22:32:07 GMT

I would argue for a presentation model that sits between the Domain Model and UI. This additional layer has the necessary logic to query the domain model and interpret domain information and put it in a presentation friendly format. For example, in the Domain Layer there may be a LastParoleReviewDate but for the purposes of the UI we just need a flag on the page ParoleReviewedInLastSixMonths. The Presentation Layer is responsible for this. This doesn't contaminate the Domain Model and can be easily tested. For things like CanSendToWork(), I like Jeremy's suggestion of creating Commands. So SendToWork is a meaningful Command it does exactly what it says on the packet and a method of CanExecute() makes it obvious where to find the permissions to use that command. Again, this is easily testable. As a final note, methods like CanBePutInIsolation and IsEligibleForVacations do not sound like methods of Prisoner but are more in keeping with a service class that is related to the prisoner and/or the prison depending on the business case.

Belvasis commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 21:57:44 GMT

I think the UI never should make any descisions by it self, because any decision is based on a specific business logic. In my apps every Button starts a specific UseCase and every UseCase is based on a UseCaseDefinition. The UseCaseDefinition has a collection of Rules attached and the availability of a UseCase is checked against those rules by a UseCaseBuilder, based on the current context in wich the UseCase should be run (here the prisoner). Since these rules are injected it is easy to extend the RuleSet with no further dependencies. And since any Rule can use any service, there is no need to duplicate functionality. So if you have for instance an other button "Can receive visitors" you have no need the change the entity model by providing a new method CanReceiveVisitors, wich is for my understanding the main problem in the above sample.

Cassio Tavares commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 21:39:46 GMT

Hi Kyle. Sorry if was not clear enough. I will not duplicate the code and I don't have functions called Simulate or Commit. I will try to explain with a simpler code: public class DomainFoo { private string Description {get;set;} public string GetMixedDescription() { //A lot of operations with Description. Whatever } } public class DTOBar 1) Let's suppose in UI I want to show the MixedDescription after user inform the description. - This is what I called simulate 2) I don't have a DomainFoo object to make it to me in UI 3) I don't want to duplicate the code to generate MixedDescription in DTOBar - As you pointed 4) I have to put this function somewhere else. What I was saying is that I wanted to let id in the domain but I can't because I'll need to use it in UI. In some cases, where I don't find a good place to share, I have to put it in some kind of Util class, what Oren said is a bad pattern and I agreee. Maybe there is a pattern that I don't know to better solve this problem.

Tobin Harris commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 21:39:41 GMT

I can feel the problem; all those GUI-friendly methods makes an object more of a GUI whore than a hard-core-business-logic-unit. I've seen the problem before, and also wondered how to approach it. Like others, my inkling is to introduce a DTO/view model/mediator/adapter/decorator or memento; one of these can be the responsible spokesman who presents or extends the object in a useful way for the GUI. What's annoying is that all these solutions mean adding more *stuff*. I'd want to find a way of adding a "GUI informer" that keeps the domain clean. Do we need a new paradigm ;)

Shane Courtrille commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 20:48:58 GMT

That makes a lot of sense Sebastian and follows in line with how I work.

Frank commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 19:43:35 GMT

Like alot of others, the decision whether a prisoner can go on a vacation does sound like domain logic to me and not an UI decision. The UI only decides how to represent this information (disabled buttons, invisible buttons, error message when you click the button).

Alois Kraus commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 19:29:22 GMT

In that case I would make it two staged. First request vacation which does only return the state if the action is possible. When we click on the enabled button then we try to execute the action a second time which we commit immediately to ensure that changes in the DB represent the most up to date data. If you let the UI e.g. two days alone and then commit a vacation request it could fail miserably in reality due to changed constraints. class Logic { Response RequestVactionForPrisoner(Prisoner p) { if( !Rules.CanGoOnVacation(p) ) return new Response( Rules.DenyVacation(p), p ); return new Response( Rules.AllowVacation(p), p ); } } class Response { public bool CanCommit; public void Commit(); } So we have public void UpdateButtonsForPrisoner(Prisoner p) { Response p = Logic.RequestVactionForPrisoner(p); cRequestForVactionButton.Enable = p.CanCommit; } public void OnClickRequestForVacationButton(Prisoner p) { Logic.RequestVactionForPrisoner(p).Commit(); }

Carlos Cubas commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 19:00:24 GMT

Alois, Though I like your approach, I don't believe it solves the original problem posed. If you read carefully the problem has to do with the fact that he wants to disable the actions not allowed for this entity.

Alois Kraus commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 18:52:58 GMT

I think you are asking for a request message like RequestVactionForPrisoner(). In the UI you can decide to give it a try but the request may not succeed because there are conditions (like "did escape during last vaction") that should be checked in the domain model to prevent you from doing something stupid. Entering data into the DB without validation is always a bad idea. Yours, Alois Kraus

Kyle Szklenski commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 18:24:38 GMT

Cassio, I don't get it. There should never be any reason to duplicate logic, or do any real business logic, in your UI directly. What you're suggesting points to a large hole in your domain that is just missing - it might be that the business just doesn't recognize it's missing (very possible), or that a mistake was made. Without knowing a lot more about what domain you're talking about, it sounds more like you need a domain object that can do a Simulate and a Commit function - these call to a private method on the domain object that does the same thing, only the second one actually commits the change to the appropriate place. Of course, this is kind of assuming an ActiveRecord-like approach, which it may not be, but you should give more details if you need better answers. :)

Cassio Tavares commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 17:25:25 GMT

I asked Oren few days ago where should I put rules since I have Domain Objects and DTO's. He answered me to make real logic in Domain and just copy the results to DTO's properties. This is similar to what peter is suggesting here but it didn't solves all cases I have a more problematic scenario where I really need to put the logic in UI and in Domain. One example would be that in UI I want to simulate and in Domain I really want to do it. If I do it twice I have to do it exactly the same and alway update both. If I do it in a common place I end up putting it in my Utils class. And Oren talks about this here: [ayende.com/.../...y-util-amp-common-libraries.aspx](http://ayende.com/Blog/archive/2009/04/29/let-us-burn-all-those-pesky-util-amp-common-libraries.aspx) In my case I wanted to simulate payments conditions.

Chad Lee commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 17:08:00 GMT

I don't see a problem here with the way it is implemented. And most of the solutions to the "problem" presented here seem to overly complicate the whole system for the sake of what? And I also agree with Sebastian. Domain logic _would_ be using these methods -- like in the AssignToWork method which would need to make sure the entity still CanSendToWork.

Jason Y commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 16:58:37 GMT

Given components A and B where A depends on B, you don't want B to be designed to meet A's every whim and fancy. In such a case, Visual Studio may perceive a 1-way dependency, but in fact there is a 2-way dependency in design. I think this is one of the arguments against certain uses of the repository pattern, right? That is, repositories too often look up in the stack to the UI layer to see what it wants. Instead, ORM tools (like NHibernate) only look down to the store layer to see what must be done to abstractify interactions with the DB for any hypothetical app. More generally, B should remain ignorant of A, both in code and in design. If you need another set of abstractions tailor-made for A, you can have those as a well-defined part of A, resulting in high cohesion and low coupling.

Jason Meckley commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 15:53:10 GMT

As others have pointed out, the domain queries are specific to the presentation and the presentation should have it's own view model. I would see an object building the view model which will control the view. public class PrisonerViewModel { // id, name, list of events public bool CanBePutInIsolation; public bool IsEligibleForVacations; public bool CanSendToWork; } class PrisonerViewModelBuilder { public PrisonerViewModelBuilder(IPrisonerViewModelBuilderPart[] parts) PrisonerViewModel BuildFrom(Prisoner prisoner) { var viewModel = new PrisonerViewModel { Id = prisoner.Id, Name = prisoner.Name, Events = prisoner,Events.ToArray(); }; foreach(var part in parts) { part.Build(viewModel).From(prisoner); } return viewModel ; } }

Jérémie commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 15:34:30 GMT

If you want to achieve CQS, your presentation never ask entities for their state. It will use a query service that will return DTOs containing domain state. So no need for your entity to provide these methods.

Daniel commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 15:31:38 GMT

I'm liking ViewModel for this type of thing, at least for MVC apps. In this example, I would use the name [ModelName][ViewName]ViewModel. So, NOT PrisonerViewModel, but PrisonerIndexViewModel, since there may be 10 Prisoner-related view models. The logic that builds out PrisonerIndexViewModel can live where you want- generally not in the controller, and definitely not in the View. One interesting place is in the class itself: var model = new PrisonerIndexViewModel(prisoner); The right location for the logic really does depend on how many UIs you have hanging from it and how large the application is.

Christopher Bennage commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 15:08:49 GMT

Another question to consider: will the application have more than one UI? If there is an html and desktop client, that could affect my decision about where the logic lives.

Sebastian Markbåge commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 15:05:17 GMT

Shane, as for CQS, it's more about avoiding queries internally issue commands, than commands internally issue queries. To avoid side effects. I.e. SendToIsolation doesn't return anything so it's a command. Take the Wikipedia sample of a command... It is "querying" X for the current value internally and incrementing it. void increment_x() { x=x+1; }

JC commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 15:00:21 GMT

How about specification? CanBePutInIsolationSpecification : Specification

Shane Courtrille commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 14:05:02 GMT

We try to practice CQS so we wouldn't have those methods on our domain objects since the domain itself doesn't need them. We would instead query for the answer from the database directly and translate those results into a DTO. The question becomes where does the business logic for the decision live? Two options I see are.. 1. Criteria objects which Business Logic in them.. 2. Prisoner tracks CanBeIsolated but doesn't allow access via getter/setter. It seems to me that CanBeIsolated might require a lot of different variables. Having the Domain Prisoner track all these changes might get messy so I'd probably look at the criteria option more closely.

Rob commented on Avoid externalizing decisions from your domain model

Tue, 09 Jun 2009 14:03:23 GMT

Well, assuming that the information isn't rapidly changing, you could abstract the notion of a prisoner action and ask the domain model for them during initialization of the screen. So you could have something like this: public class Presenter { private Prisoner currentPrisoner; public void Initialize() { foreach(var action in currentPrisoner.GetAvailableActions()) { ToolBar.Add(action); } } } Where action is an implementation of the Command pattern.