C#-DDD: Which layer DTO belong into?

4
votes

I am a new comer in DDD concepts and I am trying to design a solution structure strictly follow DDD & Prism (WPF). I am stacking at where to create DTO project (Data Transfer Object). As I know, DDD will have 4 general layer:

Presentation

Application

Domain

Infrastructure

So that, would you please tell me which layer for the DTO project belong to?

I have refered at: DDD - which layer DTO should be implemented Some one told that we should implement it at Service layer, but I think It is not make sense, cause of follow DDD concept, we don't have which called Service layer.

Thank you so much,

Regards

3
c#domain-driven-design
DTO is for DataTransferObject and is used most times to transport data between the layers. There are some assemblies which will be used as a bridge between the layers – Sir Rufo
@SirRufo Thank you, I understand it. But I don't know which layer I should use for creating a DTO project? – Khoa DANG TOAN
Read this book: martinfowler.com/books/eaa.html – Wouter van Vegchel
@KhoaDANGTOAN Well you have data and some kind of service to handle that data. Describe the data structure with DTO classes and the data services as interfaces. – Sir Rufo
@ConstantinGALBENU "A lot of DTOs where flying around between the layers just to follow the strict version of the architecture" I'm just trying to figure out why you would have less DTOs with other architectures. I mean, the DTOs are most likely needed at the system boundaries independently of the chosen architecture? – plalx

3 Answers

5
votes

Generally speaking, the location of the component's code should stay besides the owner of that component. The owner has full control of its components. This idea follows the dependency inversion principle.

So,in your case, who is the owner of the DTO? Who controls the structure and the purpose of that DTO?

Using DDD (in any architecture!) you should, however, take into account that domain code should not depend on infrastructure, application or UI code. So, if you decide to put the DTO class into the application layer then you cannot refer to that DTO from your domain code (i.e. a domain entity or a domain service cannot have any references to the DTO class - no import or use directive or new statements)

4
votes

You might be disturbed by my answer, but I have to repeat again:

Domain-Driven Design is not about layers. It is about Domain and Design.

Domain is your problem space. This is what your users need. This is what your domain experts tell you to do.

Design is how you model your solution. It starts from the knowledge you got by speaking to domain experts. It continues with deciding what are your bounded contexts and how they are placed on the context map. Then you decide how to implement each context - would this be a Domain Model, Active Record, CRUD or some off-the-shelf software.

When you decided on the implementation, you can think of the internal structure and DDD does not dictate anything there.

If your question is where to put DTO for the data - well, they might be located in a separate project if more than one other project uses them, or you put them to the DAL (which is typical) since your presentation layer will most probably use it directly, without involving the domain model, otherwise you won't be mentioning DTOs at all.

Concerning using the term DDD for your question, I wrote a blog post some time ago, targeting this issue, which you might want to read.

0
votes

I see that we should add DTO classes in the layer will create objects of them to send their to another layer. In DDD model the Application layer and Infrastructure layer already can access the Domain layer so they don't need DTOs in the infrastructure layer because it will return entity class.

Based on the above we need DTOs to represent the data retrieved from the DB(through Infrastructure layer) in the Application layer and send these data using DTOs to the Presentation layer without making Presentation layer get access the domain entities which are contained in the Domain model layer.

Finally, from my experience and using the DDD model I prefer to add DTOs in a separate project inside the Application layer. which means it belongs to the Application layer.

You can see the sample of my project and the "Core layer" in it means the "Domain Layer" DDD model example

Also you can read Excellent detailed explanation for DDD model from Microsoft