Domain Model Vs Persistence Model

Persistence model pm for the sake of this article i am going to call the set of orm entities in a project the persistence model of that project.

Domain model vs persistence model. Domain model dm it is your domain entities. Keep in mind however that a bc or business microservice could sometimes be composed of several physical services that share a single domain model. On the other hand persistence model will map one to one to database table and is the target of ef code first. A use a separate domain and persistence model will need to write some persistence code which can get challenging great domain encapsulation pure domain models.

They have pretty different purposes. Store and retrieve data. When models in both domain and persistence layer seem to be identical an idea in developer s head is born. That might be a good idea whenever there is a strong tendency to model data one to one or whenever development is database first driven not domain first.

The persistence model models what and how data is stored it models storage structure. Introduction of a persistence model is inevitable in this case if you want to have a more or less isolated domain model. Using a single model if your database schema is very simple and you dont have many invariants to adhere is also fine. The domain is the reason the application exists and everything gravitates around it.

However such situation is a sign of a bigger problem. The domain model models real life problems and solutions it models behavior. B use one model for both domain and persistence faster development bad domain encapsulation makes it easy to break domain rules. Define one rich domain model for each business microservice or bounded context.

However hiding the domain model s internal state completely will make it much more difficult to map to persistence model. It is the set of entities mapped to your database using an orm framework. This is where ood fits into your code and where you code business logic. More control over your queries without necessarily relying on navigation.

The problem here is that the application s database shouldn t be treated separately from the regular code base and must evolve with that code base hand by hand. That way the domain model objects are forced to provide business related logic to manipulate their internal state. Instead of modelling the domain logic with separate model classes that are similar to the persisted entities implement it in service classes that consume the domain entities. If you choose to keep separate domains however not only your domain model will be more expressive but your persistence will benefit from it too.

Let s merge them. Your goal is to create a single cohesive domain model for each business microservice or bounded context bc.