Does DDD encrourges the use of DTO?

[Ken1]

To have the good encapsulation of the domain entity , DDD suggests do not expose the setters of the domain entity to the client. Instead , client can only change  domain entity 's properties through some business methods defined on the domain entity.

But some presentation layer technology such as JSF requires the model in the UI backing bean has the standard getter /setter Java bean convention. If the structure of the entity that is required to be handled by the UI is exactly the same as the domain entity , we cannot directly bind the domain entity to the JSF 's UI backing bean .Instead , I always have to make a DTO for each entity and convert the domain entity to this DTO such that it can be handled by the JSF. It seems that a extra layer of complexity is added in such case as we have to maintain a set of domain entity and its DTO which are exactly have the same structure.

Please correct me if I am wrong , and any pattern or solutions in it ?

Thanks

[Bennie Kloosteman]

On Fri, Dec 14, 2012 at 12:09 PM, Ken1 <kenc...@gmail.com> wrote:

e good encapsulation of the domain entity , DDD suggests do not expose the setters of the domain entity to the client. Instead , client can only change  domain entity 's properties through some business methods defined on the domain entity.

But some presentation layer technology such as JSF requires the model in the UI backing bean has the standard getter /setter Java bean convention.

DTOs in your query side is standard , and the client normally doesn't  have direct access to the domain objects anyway... query side is  created from events generated by the command side . but the Aggregates themselves should be  fully encapsulated .. IMHO the tight domain  is the best part of CQRS .  

 

If the structure of the entity that is required to be handled by the UI is exactly the same as the domain entity , we cannot directly bind the domain entity to the JSF 's UI backing bean .Instead , I always have to make a DTO for each entity and convert the domain entity to this DTO such that it can be handled by the JSF. It seems that a extra layer of complexity is added in such case as we have to maintain a set of domain entity and its DTO which are exactly have the same structure.

Remember things like Name strings which have no relation to business  logic should not be in your domain so its pretty hard to get a 1: 1 relationship ...   In most cases you dont convert the domain entity ,  the domain entity fires events which are used to create data for the query side .

That said there are cases where the setters and getters were exposed normally to talk to a non event sourcing DB  . have a look at the Journey . I went down this path first but decided that the event sourced model was simpler and better ,  if you go the traditional way then there is little point in separating things into commands and queries unless your dealing with really large transactions volumes .

Ben 

[@yreynhout]

Models for UI almost never match up to domain models. It's a fallacy to think and do so. Change is going to come, inevitably (why we ended up separating in the first place). But don't take my word for it. Make your own mistakes. #bestschoolever

[Dennis Traub]

If your domain classes and your UI DTOs just mirror and match each other you either didn't put much effort into a tight model of the domain or it is rather simple and CRUDy. If it's simple you don't need DDD in the first place. If it's not that simple you probably want to put more effort into a tight domain model.

[Greg Young]

queue the naked objects guys ....

[Bennie Kloosteman]

 cryptic...

[Bennie Kloosteman]

Agree there though i would qualify it with "good" UI 's   , CRUD UIs will often make the UI match the data for low to medium complexity.  Until you got a client who goes "I want this " then your screwed . For , setting/ db /maintenance  screens you can get away with it nor do you want to sink too much time there.

Ben

[@yreynhout]

I spend at least the same amount of time on administrative screens as I do on end-user screens. I'm biased due to the domain I work in. They affect the past AND the future, or at least require one to think in those terms. The admin screens also have a more complicated statechart (especially with master/detail on the same screen).

[Peter Ritchie]

Greg is saying that the guys who evangelize Naked Objects should be jumping in the conversation...

---

From: Bennie Kloosteman
Sent: 14/12/2012 5:05 AM
To: ddd...@googlegroups.com
Subject: Re: [DDD/CQRS] Does DDD encrourges the use of DTO?

[Greg Young]

and i meant cue :)

[Johanna Belanger]

You might be a software developer if...

You say queue when you mean to say cue. =)