Domain Object extends Data Transfer Object

Question

I'm new to DDD and OO principles, sorry for my poor knowledge.

I have CustomerDTO and Customer classes.

I store all fields and properties in DTO class and use it as Base class for Customer class.

Main purpose of using DTO is to pass it to View. I've extended it in Customer class not to have duplication of properties.

Is it right way to do this or there's better OO solution?

I've read about AutoMapper, but I'd like to know, if there's alternative solution.

Many thanks for any kind of help.

Answer 1

I have personally never seen this approach. The reason you use a DTO is to seperate concerns between the DAL and the biz layer. It lets the business layer and the DAL change at their own paces with minimal side effects. All you have to do is change the mappings between the DTO and DO. If you inherit your DO from your DTO, whats the point of even having a DTO?

Quick answer: do not inherit your DO from your DTO. It might be easy now, but it may be a maintanence nightmare in the future.

PS Don't be afraid of Automapper. Its relativly easy to use.

Answer 2

This is a bad idea. Here are two reasons (there's probably a few more) why:

• Domain Objects are specifically structured for transactions. They should not provide public access to all properties. They should only contain properties that provide behavioral purpose. DTO's have one purpose: to provide data to a consumer (such as a UI/Web Service/Message System). For example, a customer DTO may contain a properties that provide the number of orders that customer has made, and the total amount of money they have spent. On the domain side however, the Customer aggregate will probably not contain any of this information as this order information is stored in a separate order aggregate specifically tailored for order transactions.
• DTO's are dumb POCO's with just a bunch of getters & setters. It is very bad practice to allow your domain objects to have setters on all of their properties. Operations should be atomic and provided by methods that have explicit names describing their intent. The answer to this question explains this point.