CODEWITHSUNDEEP
c#domain-driven-design
Khoa DANG TOAN
Khoa DANG TOAN

Reputation: 263

C#-DDD: Which layer DTO belong into?

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

Upvotes: 4

Views: 5302

Answers (3)

Youssef Ali Youssef
Youssef Ali Youssef

Reputation: 159

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

Upvotes: 0

Alexey Zimarev
Alexey Zimarev

Reputation: 19630

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.

Upvotes: 3

Constantin Galbenu
Constantin Galbenu

Reputation: 17683

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)

Upvotes: 6

Related Questions