anemic domain model versus domain model

Question

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.

Answer 1

But if I add enough domain logic on that wrapper, at what point does it become a real domain model then?

Arriving at the domain model by means of adding stuff in a haphazard manner is possible, but certainly not domain driven design. (I know this is not really helpful. I tend to think very data-centric myself, and in some cases it takes a real effort to pull oneself from this viewpoint.)

Answer 2

Two items of interest come to my mind:

• Data Transfer Objects (DTOs) are different from Domain Objects. They serve different purposes in different places in an architecture - don't confuse them. Domain Objects provide a rich API with high cohesion. DTOs are passive data structures used in an application's external interface - quite like UI ViewModels, but aimed at automated systems instead of users.
• Strive after selecting an ORM that allows you do employ Persistence Ignorance. This means that you can define your Domain Model in an unbounded way, and simply have the ORM map the objects to a relational database.

Answer 3

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...