DTO (data transfer object) is just a data structure, it doesn’t affect “purity”.
Layers should be decoupled, so that changes in one of them don’t affect others. DTOs are one of the ways to do that.
In the domain layer, DTOs can be the domain entities themselves. In other—specific objects designed in a way to provide only as much information as needed.
(You can find out more about this in, for example, “Domain Modeling Made Functional” and “Domain Driven Design”.)
But again, not every project needs this. Smaller apps can live without that strict separation. Every solution depends on the particular problem 😃
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As I mentioned in the post, the canonical way assumes distinction between the functionality.
That means, there not only should always be the application layer, but also layers should have their own DTOs.
However, not every project needs all this. In the post, I mentioned a couple of reasons for not using all of the “canonical stuff”.
well , if domain have DTO, it then has side effects, no good for tests I think, Is there a principle like "keep domain layers pure, easy to test" ?
DTO (data transfer object) is just a data structure, it doesn’t affect “purity”.
Layers should be decoupled, so that changes in one of them don’t affect others. DTOs are one of the ways to do that.
In the domain layer, DTOs can be the domain entities themselves. In other—specific objects designed in a way to provide only as much information as needed.
(You can find out more about this in, for example, “Domain Modeling Made Functional” and “Domain Driven Design”.)
But again, not every project needs this. Smaller apps can live without that strict separation. Every solution depends on the particular problem 😃