C# – Pitfalls of Domain Driven Design with Entity Framework

cdesign-patternsdomain-driven-designentity-frameworkobject-oriented-design

A lot of tutorials on DDD I studied are mostly covering theory. They all have rudimentary code examples (Pluralsight and similar).

On the web there are also attempts by a few people to create tutorials covering DDD with EF.
If you begin studying them just briefly – you quickly notice they differ a lot from one another. Some people recommend to keep the app minimal and to avoid introducing additional layers e.g. repository on top of EF, others are decidedly generating extra layers, often even violating SRP by injecting DbContext into Aggregate Roots.

I'm terribly apologizing if I'm asking an opinion-based question, but…

When it comes to practice – Entity Framework is one of the most powerful and widely-used ORMs. You will not find a comprehensive course covering DDD with it, unfortunately.

Important aspects:

  • Entity Framework brings UoW & Repository (DbSet) out of the box

  • with EF your models have navigation properties

  • with EF all of the models are always available off DbContext (they are represented as a DbSet)

Pitfalls:

  • you cannot guarantee your child models are only affected via Aggregate Root – your models have navigation properties and it's possible to modify them and call dbContext.SaveChanges()

  • with DbContext you can access your every model, thus circumventing Aggregate Root

  • you can restrict access to the root object's children via ModelBuilder in OnModelCreating method by marking them as fields – I still don't believe it's the right way to go about DDD plus it's hard to evaluate what kind of adventures this may lead to in future (quite skeptical)

Conflicts:

  • without implementing another layer of repository which returns Aggregate we cannot even partly resolve the abovementioned pitfalls

  • by implementing an extra layer of repository we are ignoring the built-in features of EF (every DbSet is already a repo) and over-complicating the app

My conclusion:

Please pardon my ignorance, but based on the above info – it's either Entity Framework isn't adequate for Domain-Driven Design or the Domain-Driven Design is an imperfect and obsolete approach.

I suspect each of the approaches has its merits, but I'm completely lost now and don't have the slightest idea of how to reconcile EF with DDD.

If I'm wrong – could anyone at least detail a simple set of instructions (or even provide decent code examples) of how to go about DDD with EF, please?

Best Answer

DDD and EF have little to nothing to do with each other.

DDD is a modeling concept. It means to think about the Domain, the Business Requirements, and model those. Especially in the context of object-orientation it means to create a design which mirrors business functions and capabilities.

EF is a persistence technology. It is mainly concerned with data and database records.

These two are sharply divorced. A DDD design may use EF in some form under the hood, but the two should not interact in any other way.

Some interpretations of Domain-Driven Design do actually advocate data-modeling, and I think this is what your question is about. In this interpretation "Entities" and "Value Objects" are essentially function-less data holders only, and the design concerns itself with what properties these hold and what relation they have between each other. In this context DDD vs. EF may come up.

This interpretation however is flawed, and I would strongly recommend ignoring it altogether.

In conclusion: DDD and EF are not mutually exclusive, they are actually irrelevant to each other, as long as you are doing proper object-modeling and not data-modeling. DDD objects should not in any shape or form be EF artifacts. DDD Entities should not be EF "entities" for example. Inside some business-relevant function, a DDD design might use EF with some related data-objects, but those should be always hidden under a business-relevant behavior-oriented interface.

Related Topic