C#-DDD: Which layer DTO belong into?

Question

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

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, May 09 '17 at 06:00
@SirRufo Thank you, I understand it. But I don't know which layer I should use for creating a DTO project? — Khoa DANG TOAN, May 09 '17 at 06:03
@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, May 09 '17 at 06:14
@ConstantinGALBENU To get a maintainable, testable and flexible solution? — Sir Rufo, May 09 '17 at 06:22
Your goals are OK however the Layered Architecture is quite ...old, so to say. I've worked with it in the past and I did not liked it. A lot of `DTOs` where flying around between the layers just to follow the strict version of the architecture. That was a good wasted time because I've learned (the hard way) what are the downsizes of this architecture. You could make the same mistake in order to learn or you could just try another architecture. Do you agree? — Constantin Galbenu, May 09 '17 at 06:25
In that SO question "Service layer" means "Application Layer as a service" — Constantin Galbenu, May 09 '17 at 08:55
@ConstantinGALBENU To be honest I can't see the practical distinction between the layered architecture with dependency inversion and other architectures such as the hexagonal or port & adapters architectures. I mean, the `infrastructure` layer seems pretty much to covers port & adapters and there is always a need for some sort of application layer. — plalx, May 09 '17 at 12:54
@plalx In layered architecture (both strict and relaxed) the Domain depends on the Infrastructure. In the hexagonal and port&adapters the dependency is inverted (as it should be!) — Constantin Galbenu, May 09 '17 at 12:58
@ConstantinGALBENU Sure ;) Well if you apply the dependency inversion principle to the traditional layered architecture you get the same result. — plalx, May 09 '17 at 13:27
@plalx yes, it is a well known fact but one must notice that important aspect. — Constantin Galbenu, May 09 '17 at 13:29
@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, May 09 '17 at 13:35
@plalx with CQRS I have `DTOs` that go directly from DB query to UI. In the strict layered architecture one must convert from `Domain DTO` to `Application DTO` before passing to `UI` otherwise the architecture would not be `strict`, it would be `relaxed` — Constantin Galbenu, May 09 '17 at 13:38
@plalx anyway, some time later I say that I was using the DTOs as an anti-pattern. Read this: https://martinfowler.com/bliki/LocalDTO.html — Constantin Galbenu, May 09 '17 at 13:54

score 6 · Answer 1 · answered May 09 '17 at 09:03

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)

score 4 · Answer 2 · answered May 11 '17 at 08:04

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.

score 0 · Answer 3 · answered Jun 08 '21 at 18:40

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"

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

C#-DDD: Which layer DTO belong into?

3 Answers3