Just Stop It! The Domain Model Is Not The Persistence Model

By Mike on 7 April 2012

I think 90% of times I see a DDD question on StackOverflow, it's something like this: 'I have this domain object' and the code shows an EF (Entity Framework) or NH (NHibernate) entity.

NO! This is WRONG (99% of times anyway)!

I've said it before and I repeat it:

  • The Domain Model models real-life problems and solutions, it models BEHAVIOR.
  • The Persistence Model models what and how data is stored, it models STORAGE STRUCTURE.

See? They have pretty different  purposes. The domain is the reason the application exists and everything gravitates around it. The domain should not depend on anything,especially not on a persistence IMPLEMENTATION DETAIL like EF or NH. When you design the Domain Entities, they don't know anything about persistence. Persistence, database, doesn't exist.

When you design the Persistence Layer, that layer serves the Domain and depends on it. So the persistence needs to know about the domain but not vice-versa. You design the persistence entities for storage purposes and to match the ORM's constraints (like making all the properties virtual). So you'll have Domain Entities and Persistence Entities, each with their own different purposes and implementations.

Yes, they do resemble and sometimes can be identical (when the domain is very simple) but that's nothing more than a mere coincidence. Every time you're modeling something in a repository or using an ORM , you are modelling the persistence NOT the domain. There is a reason Eric Evans recommends to start the app with the domain and to IGNORE anything db related: the Domain should not be tainted with infrastructure details, because most of the people start everything with a database centric approach. And once you start with the db, everything will evolve around it and will be constrained by it. But you don't build the application for the database, you build it for the Domain, the database is just a Persistence implementation detail.

In conclusion, repeat after me: the Domain Model is NOT the same as the Persistence Model. Each serve a different layer with different responsibilities.

Comments (9) -

pebrian27
pebrian27
11 August 2012 #

People probably just want to avoid duplication. There is already domain model, persistence model and commands or DTO. Also, if you look into the code sample jointly developed with Eric Evans, it persists the domain model itself because NHibernate can access private members and doesn't require a public parameter-less constructor.

http://www.domaindrivendesign.org/examples

This of course isn't applicable to all cases. It's much worst when you use Entity Framework since it requires public properties and a public parameter-less constructor.

Reply

pebrian27
pebrian27
11 August 2012 #

By the way, you can also extend NHibernate to map 1 or more columns to a custom object (you can even use a factory pattern to create the object) unlike entity framework.

Reply

Grzegorz
Grzegorz
18 July 2013 #

Thank you sir. You depicted something I was struggling with for several days - how to isolate entities from the database. Entities are no longer associated with the database then Smile

Reply

qwertyer
qwertyer
14 December 2013 #

Thank you sir. You depicted something I was struggling with for several days - how to isolate entities from the database. Entities are no longer associated with the database then

Reply

andrew
andrew
21 December 2013 #

If we separate domain models from persistence models, then how can we create specifications for domain models so that put them as repository argument. How repository can use EF or NH along with specification for domain model?

Reply

Admin
Admin
21 December 2013 #

You create a criteria object that can be used by the repository to create the proper query.

Reply

andrew
andrew
22 December 2013 #

I asked in details the same question in stackoverflow

stackoverflow.com/.../how-to-build-ef-query-expression-for-persistence-model-using-specification-for-d

it is not clear enough how avoid DRY principle when build query expression for EF in repository?
can you show some source code here please ))))

Reply

andrew
andrew
22 December 2013 #

sorry, keep DRY principle )))

Reply

Admin
Admin
23 December 2013 #

It's not a DRY violation, I'll write a post soon about DRY.

Reply

Pingbacks and trackbacks (1)+

Add comment

biuquote
Loading