Graphinder – Domain models vs Persistence models


As we’ve moved on from domain logic of optimization problems and algorithms for solving them, I’d like to start a series of few post about approaches of working with persistence layer. Today I’d like to elaborate a little about differences and usage of domain models vs persistence models (also called ‘entities’ in ORM world). But first of all, let’s start with few words about each of model types, what they are and what we’re using them for. For each example I will assume that we’re using Entity Framework 6 as an ORM of choice for each example.

Domain models vs Persistence models – what and what for?


Domain models

Generally speaking, models that represent closely as possible real world and its objects. In both pure DDD and in OOP in general we would see such models taking responsibility for some of the business logic that regards them (provided that SRP is not broken of course). While this approach is quite popular and is the closest to OOP paradigm, with rise of ORMs, so called Anemic Models concept have emerged. In such approach, models are mostly property bags and their business logic is often placed higher, in Service Layer. I do strongly oppose such approach, but there are possibly cases (like RAD approach) where it makes sense, whenever high re-usability is encouraged.

Persistence models

While in many cases domain tend to be simple and easy to persists as-is, it also tends to grow in complexity during application life cycle.
Persistence models attempt to solve that problem by abstracting away model representation required for persistence, that would often be considered at least inappropriate if not wrong in business logic world. When domain is simple, we can often just map properties one-to-one with some ORM-specific changes to meet persistence requirements. It’s also the moment when we think of merging two mentioned models into one. But should we?

Domain models vs Persistence models – to separate or not?

When models in both domain and persistence layer seem to be identical, an idea in developer’s head is born: let’s merge them!
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 driven. Whenever organization has at least few DB Admins/developers or analytics that model domain with client with ready to convert UML diagrams, that might be an often to see approach.

Simple domain

Let’s take a look on two sample models, that look almost the same and seem to be ideal candidates for merging.
They might come from Database-First approach or domain is so simple that it’s one-to-one mirror of persistence layer.

As Persistence models can enter invalid state as opposed to domain models, we might want not to bother even with encapsulation, as they won’t ever leave Persistence Layer at all. For Entity Framework purposes, we also needed to refactor Subordinates signature to virtual ICollection so that EF6 can create proxies for N-to-Many relationships.
Now if we think of merging those two models into one, that would be a no-brainer:

A must have that have been applied here is a parameterless constructor that Entity Framework will use to populate properties through reflection.

A not so simple domain

Now let’s think of a problem right from the Graphinder project. Let’s take our Simulated Annealing algorithm and all the possible cooling strategies it can use. I need to actually map interface to DB here:

But how do I map it to database? I cannot treat each implementation as separate entity (I mean, I can but it won’t make sense) as there won’t be any difference between them. ICoolingStrategy looks like this:

So.. what can I do?
I can introduce some sort of factory based on persisted enum, defining type of strategy, to be recreated on deserialization, ie:

Now I can recreate appropriate strategy whenever needed.
But strategies I use in algorithms are stateless. What if I have several implementations of interface that have state?
Well, then if there is only difference in logic, I could go with Table per Hierarchy (TPH) approach in Entity Framework and let it create a so called ‘Discriminator’ or even flatten the hierarchy to one entity myself.
But what if implementation might differ throughout the hierarchy?
Well, then the only valid way would be to go with Table per Type approach to have both flexibility and reusability preserved in case anything changes.

Domain models vs Persistence models – when to use what?

After doing a lot of research, I came to conclusion that whenever possible, go with both and even introduce ViewModels as additional representation used only by views. If you find yourself flexible enough without Persistance Model approach, make sure that you don’t throw around Domain models everywhere, make a clear separation.

    Finally, things to keep in mind when making decision:

  • Even if you decide to skip any of model types, make sure that domain has no idea how to persist itself – it’s persistence layer responsibility!
  • Make sure that you don’t throw around the same model throughout whole application. Entity might be good for persistence layer, but throwing it to your views can end up in some mumbo jumbo code in the end!

One thought on “Graphinder – Domain models vs Persistence models”

Leave a Reply

Your email address will not be published. Required fields are marked *