Local DTOs & Fowler

10 Comments

• "This is one of the reasons I think Microsoft should not push an architecture based on a 'pure' domain model. It will make building smart client applications harder."
  
  
  
  I don't see your point here. Why will pure DDD make it harder for validation? A validation checks for something that must be valid by some criteria. Maybe an e-mail address, an input that only contains numbers etc... The Validation has nothing to do with the DDD.
  
  
  
  Best,
  
  Johan
  
  

• Hi Andres,
  
  
  
  "This is one of the reasons I think Microsoft should not push an architecture based on a 'pure' domain model."
  
  
  
  Hey, they don't *exactly* push that do they?
  
  ;-)
  
  
  
  What are the other reasons why you don't think they should push it as *one* useful approach?
  
  
  
  Best Regards,
  
  Jimmy
  
  www.jnsk.se/weblog/
  
  ###
  

• Jimmy,
  
  
  
  The other one is that a domain model works well inside on tier. If you want to use it from a different tier 'as it is', then you get into a lot of trouble.
  
  
  
  Following Fowler, if you go n-tiers you need to use DTOs. Your DTOs look similar to your domain model but they are not the same. So you will have two sets of 'domain models' to maintain, one for each tier.
  
  
  
  That's why Fowler, quoting Randy Stafford says "Don't underestimate the cost of [using DTOs].... It's significant, and it's painful - perhaps second only to the cost and pain of object-relational mapping".
  
  
  
  

• Johan,
  
  
  
  Let's say you want to check the email is valid. Where do you write that logic? In a pure DDD you'll probably do it in the .Email property. How will you do it if you have a Windows forms client in another tier? You can't reuse the same domain class because you need to use a DTO.
  
  
  
  The usual solution is to move the validation to a third class and use it from both tiers. That's 'designing with distribution in mind'.
  
  
  
  

• Hi Andres,
  
  
  
  Sure, you often need to make changes for effectively using something in another context, I agree.
  
  
  
  Or, you could design for as many different contexts as you can imagine, and by doing that paying a lot for stuff you will never need.
  
  
  
  Regarding the Email-property, I don't think that validation code should be in the property itself. It will then execute too early. But that was probably not your point.
  
  :-)
  
  
  
  If Specification pattern [DDD] is used, then you would have a slightly more distribution friendly Domain Model if I adhere to your argumentation, right?
  
  
  
  Best Regards,
  
  Jimmy
  
  www.jnsk.se/weblog/
  
  ###
  

• A Specification pattern could help, but not much. Specifications are 'predicates', but the code that compose those predicates is in the domain classes.
  
  
  
  You need to move that code out of the domain classes or rewrite it if you want to use it in another tier.
  
  
  
  

• This is one of those fundamental things that has to be worked out pretty soon after the domain is modeled: what needs to be validated, what kind of validation will we do, and where will it happen.
  
  
  
  In theory, it seems possible to share DTO-based validation in client and server-side code. In practice, I've found that what you want to validate on the client is different than what you want to validate on the server.
  
  
  
  The client tends to validate scalars (is this a valid price) and relationships between a few scalars (is the start date before the end date). The server tends to validate greater amounts of data (is this price within 20 pecent of all prices this year) as well as relationships between entities. The server also tends to make "what if" validations that shouldn't actually change domain data (what rules are violated if this end date is changed by one month).
  
  
  
  My preference is to try to share the validation that acts on scalars, but to defer the rest of the validation to the server side. I also try to keep distributed domain objects out of the validation as much as possible, for performance and transaction demarcation reasons.
  

• Hi Eric,
  
  
  
  Yes, I agree, that was what I was thinking of when I said that you have a component that you use for validation in the client and the server. In the server you'll use this component and perform aditional validations.
  
  

• Hi Andres,
  
  
  
  I'm usually a bit slow but I still, somehow, fail to grasp why separating different concerns away from your domain model into more reusable components should reduce the, well "domain-modelness" or something, of the domain model...to me, the beauty of the domain model does not lie in stuffing it with all the methods that could possibly find themselves at home in the domain objects (although I realize I do differ with some of the heavier domain model people out there on this...)
  
  
  
  I mean, we move persistence logic out of the domain objects and into a persistence framework, right? We probably move serialization out of the objects as well. And logging, and probably security. Why not validation?
  
  
  
  I don't see anything wrong with the picture Validation Framework + XML Metadata describing validation for your domain objects + your clean domain objects. The same Validation framework could even be used client-side and server-side using only different XML files as far as the required validations differ from client to server.
  
  
  
  Secondly, and I'm probably still just to dim to get it, but I'll just happily continue making a public fool of myself: I don't see why keeping the domain model server-side (i.e not remoting it) would reduce the value of it, at least not so much as to not make it useful anymore?
  
  
  
  Ok, so some of the O/R Mapping vendors/developers have reported great success with remoting their domain models, but myself I'm not there yet. I still would agree, as far as all O/R Mapping I've done, with you Andres that remoting the domain model brings along a whole sackful of troubles. So I don't remote my domain models in my rich clients. And I still see great value in using the domain model on the server side. In fact, I sometimes use a domain model at the client too, but it doesn't even have to match the domain model on the server, and it is certainly not the actual server-side domain model being remoted.
  
  
  
  So, summing up: Sure, the domain model may not be easy to remote and sure, the Validation logic should probably be moved out of the domain model - but where's the problem? I still want a domain model to work with on the server, right...or why wouldn't I?
  
  
  
  /Mats
  

• About client and server side validation.
  
  
  
  I usually use the validation control shipped with ASP.Net to validate the user inputs. Other validations are added to the business logic or by using Specifications. It depends on the business needs.
  
  
  
  Something that is not part of DDD but that I use is the MVC pattern, where I have added the validation code into my controllers, those controllers could easily be used reused by a Windows client app. If I need to use distributed objects, I will probably design my domain model to support that possibility even if most of the objects could be DTOs. I don't hate DTO and there is always different kind of solutions to solve a problem. If I don't want to DTO, I will probably use an anticorruption layer and make sure my objects are transformed into another format, which the client app could transform to valid objects it will understand and will be suited for the type of the richness the client provided us with.