Data transfer objects, a.k.a. value objects, as both those names imply, alone bear no particular behavior, and thus, so to speak, no business logic on their own. On the other hand, in the DDD approach DTOs do form a domain model, too, as they are a vital part of the "domain vocabulary". Think of them as nouns in your "vocabulary", just like business objects, but unlike them as being an object, not a subject of a "sentence", an action. This way it is fairly natural both the object and the subject come from the same, domain-specific vocabulary, and your business objects talk to the outside world and one to another by exchanging domain-specific DTOs. In fact, DTOs - more commonly under the name of VOs - are one of the substantial design patterns of DDD.

While shaping your particular domain model, for your VOs try to pick such concepts from your domain, that have no identity on their own, but rather characterize certain things by their value, qualitatively or quantitatively, as e.g. money, goods sold in bulk etc. Suppose you are modeling an office environment, where business units exchange documents - a document alone can be a so-called reference object (that's another design pattern of DDD), and hence a business object in your model, especially when the document has its identity - its number, its particular place in the folder in the archive etc. But its contents or a part of them under processing (e.g. exchanged while creating another document) are the best candidate for a VO.

Well, having said that, although DTOs and VOs are commonly perceived as synonymous, I'd personally rather say VO has a more specialized meaning than DTO - VOs are those DTOs that conform to DDD in a way they are domain-specific - they are a part of the domain model, and not just an implementation-related pattern. So, to apply DDD to your particular design, your DTOs should be VOs, too.

Links:

• http://en.wikipedia.org/wiki/Domain-driven_design

posted February 24, 2008

I favour thinking about a partitioned and layered Domain Model. At the most abstract end, the Domain Model will model only things known to relevant parties outside the business (e.g. Products, Suppliers, Customers). Then we can layer on to that some of how our business operates; if we act as an introduction service the business will not be the same as if we act as a retail outlet, for example. Here we have concepts such as Order, Delivery, Invoice etc. Again these are real things that someone outside the business would see and understand.

At some abstract level, Order is a "Transfer Object" in an abstract domain; an entity in a more concrete layer, in the domain that represents that layer. In some respects, each of these transitions between more abstract and more concrete layer are transitions between analysis and design. By analyzing the more abstract layer and making some design decisions, we build the more concrete layer. For example, by analyzing the relationship between Suppliers and Customers, we might decide that the Customer would like to have one place that he can come to view and try out all the competing products and we design our business based on that decision.

The Transfer Objects you talk about sound to be at a fairly concrete level; you have already decided to create a layered application and analyzed the information that needs to pass between the layers, now you are designing the packets of information that will communicate between the layers.

If you want to be efficient, it is important to keep much of this partitioning and layering in the mind rather than in the model. It is common to model only one or two layers though some model several, and Schlaer-Mellor fans may model many. Modelling many layers is useful and can be efficient where the code is automatically generated or when a high amount of re-use is expected. It is also important to know when to stop modelling and to build code. What happens here is that any remaining more concrete layers of potential model exist only in the minds of the developer until they are manifested in the code. For some teams, these Transfer Objects would be among those things that are only modelled in the minds of the developers.

What is right in your situation will depend on the capabilities of your developers and the way the team chooses to work. Here I'm trying to give you some help in thinking through the choices that need to be made.

Hope this helps.

posted February 24, 2008

Data Transfer objects required for presentation and persistence should preferably be inferred from business objects
Domain Driven Design enables to spend more effort on understanding and modelling the business and less on defining and implementing the enablers like presentation and persistence.
Hence TO's should preferably be inferred (read dynamically generated) by defining a standard to satisfy the persistence and presentation layers. technologies.

posted March 1, 2008

Yes. Domain objects represent business ideas. They can be anemic, w/ little behaviour, or very rich, containing computations operating w/ the data they contain.

Domain objects can be considered a subset of DTOs as domain objects can contain data in a convenient form, and be lightweight. The real value of a DTO is in its structure. If one needs one property of an object for some purpose, a domain object may be fine for that - such as in use in a template. If one needs many calculated values associated w/ domain object information as one consolidated chunk, a custom formed DTO is just fine.

Remember, domain objects represent ideas. DTOs represent more specific concepts in a convenient form.

posted March 1, 2008

The key bit to remembere here is where TOs (Transfer Objects) and DOs (Domain Objects) come from.

To me TOs are a part of the low level design, and DOs are part of the analysis/high level design.


We also have to remember why TOs became so popular. In the J2EE arena they became popular because the components which were supposted to support DOs were to say the best inadequate. Entity Enterprise Java Beans performed like a DOG in version 2.0 and previous.

This us became very popular to do the whole analysis with pure rich domain objects, then, model things down to something that would actually work.

Hence TO or VO object everywhere. This is of course not necessarily a bad thing except for the confusion you are expressing.

I would say. Start with the pure domain object model you are thinking of, and then model it closer to the real world as needed, exactly as has been done in the past. Fortunatly things like JPA, EJB 3.0, Spring and Hibernate have vastly simplified translating pure analysis models into implementable design models.

In fact with the new features in EJB 3.0 and the JPA I think we will see a convergance of VO and DO as the thrust of these technologies is to make everything a POJO (Plain Old Java Object)

Hope this helps

posted March 2, 2008

DDD is a mechanism for building out an abstraction of your domain with state and behaviours built into objects that represent items within the problem space (leading to funky code that stakeholders can almost read because it is written in business terms).

DTOs and other approaches may be used for moving data between the domain layer and other layers, however with DDD your DTOs generally become more like adapters that provide the target layer with things it needs while not polluting your domain layer with additional concerns.

In your example (binding domain objects to a web page), you might end up with more of a wrapper around your domain object that knows how to format the data as required for the web page and / or update the object if you are using some form of databinding (e.g. MonoRail SmartDispatchController DataBind attribute allows binding to complex objects).

I have successfully used a presentation wrapper approach on my current project. Where the presentation concerns are simple, I generally bind the domain object directly, however as the presentation concerns become more complex, I factor those out into a wrapper that can translate between the domain model and the page. This leaves me with a "clean" domain object and a single place to refer to any presentation mapping that must occur between the domain object and the presenation layer.

posted March 6, 2008