Being confused again after reading about this anti-pattern and the many concerns about it here on SO.
If I have a domain model and capture the data that must be persisted in a data transfer object, does that make my domain model a wrapper around the data? In that case I would be using an anemic domain model. But if I add enough domain logic on that wrapper, at what point does it become a real domain model then?
I get the impression that capturing what must be persisted in a domain model violates good practice and creates the anemic domain model anti-pattern. Yet if you use a relational DB there’s no way to avoid to single out the part that makes the state of the object and save it.
Since I’m pretty confused about the concepts I’m not sure that what I write makes sense. Feel free to ask clarification.
It becomes a ‘real’ domain model when it contains all (or most) of the behaviour that makes up the business domain (note I’m emphasising business logic, not UI or other orthogonal concerns).
If you’re using the Ubiquitous Language, and getting constant feedback from your domain experts, you’ll know that you’re on the right track (experts should nod when they see your domain model). If you’re not doing these things, you’re not doing DDD (Eric Evans speak about it).
Onto the point of DTOs: Don’t ignore them. From an implementation perspective, you’ll need them to ferry data between layers/tiers. How you combine DTOs and true Domain Objects really depends on the technology you’re using.
As alluded to in an earlier answer, maybe your focus on data and persistence is distracting you from true domain modelling…