Repository can have DTO?

Question

Hi, I have a DTO and entity e.g PersonDTO and Person. I have created a aaplication using DDD in which i have PersionApplciation which takes DTO as input and call the PersonService internally. In PersonService i get the instance of Person using PersonFactory(Only populating from DTO and setting values to Person entity).After getting instance of Person i call add method of personRepository to persist the record into DB. Again in inquire method i have to return DTO to personApplication. For this i use the approach in personService i call the PersonRepository which loads the Person entity and populate the personDTO and return personDTO to personService and personService return the DTO to personApplication.

the way i am doing is right or wrong?

Answer 1

Design is rarely 100% right or 100% wrong. It's better to start asking questions about your design, challenging your decisions and forcing yourself to reason through a logical defense.

For example, I feel like having a PersonDTO is redundant. Why can't you just use the Person Entity for both operations? It almost certainly has all of the same data fields as your DTO object. Now when you change the Person, you'll have to update two classes.

DDD also suggests that the best place for Factory and Repository logic is within the Entity class itself. For example, your Person object could have an instance method called save() which persists any changes to the database. The argument against this used to be that persistence was usually a lot of work (think of all that ORM) so it should (rightfully) be separated out. Modern persistence APIs like JPA, JCR and frameworks like Hibernate, NHibernate, TopLink, etc. make persistence of an Entity a one-liner. Likewise you could bring your Factory into the Person Entity by making it a static (class) factory method. These changes are optional, but the idea is that a Person should know how to build and persist itself.

Lastly, having a Service layer is a bit controversial. You have some OOD greats like Martin Fowler who never use a Service layer (this logic belongs in the domain), but at the same time defends those who choose to. I've found the Service layer useful as a transactional layer and an API export layer (think opening your Service API to RMI or web services).