Domain-Driven Design: where are the DTO?

Question

I have a problem with the domain-driven design architecture. Everything looks nice until I try to use REST. I should use the DTO instead of the entity on the frontend.

My architecture looks like:

My question is :

Should I use the web module and stick to it in the DTO? Is it the correct approach?

Answer 1

• Domain Driver Design (DDD) approach was introduced on 2003, by a book with that name.
• REST was initiated from the a Doctoral Dissertation named Architectural styles and the design of network-based software architectures that was only published on 2000.
  • It took some time for REST to spread, establish, and becoming popular. It probably reached "world-level popularity" roughly around ~2005-2008 .

• DDD referred mostly to isolated monolithic systems, or at least didn't cover aspects of cross system communication.

Therefore, even if you work "according to DDD", you will have to make your decisions - how to handle these aspects.

Reference: list of patterns introduce in the DDD book, with their relations:

Answer 2

You should see REST as just one of many "ports" allowing to reach your application layer services. REST, RPC, Websocket, etc. services would adapt & map input to application layer calls and vice-versa. At each service boundary you still have the flexibility to adapt responses, which does not have to have a 1-1 mapping with application service method responses, but could.

Answer 3

根据Vaughn Vernon的《实现域驱动设计》一书，DTO位于应用层中。

Answer 4

Ideally, the Domain models should be created by factories. So the factories can accept DTO and return an instance of the Domain model. Or you could use Builder pattern that accept DTO(s) to create the Domain model. This way you're domain model is kept clean from DTO and the Application layer in your architecture diagram should accept DTO(s) as parameters.

In your diagram, I am not sure what is the purpose of Application layer. Since what we call application should be the domain models.