CODEWITHSUNDEEP
domain-driven-design
NoPyGod
NoPyGod

Reputation: 5067

Mapping tables to domain classes in a DDD architecture

My application is broken down into several assemblies.

The MyProject.Core assembly contains all of the Domain objects such as Person and Sale as well as interfaces repositories such as IPersonRepository and ISaleRepository.

The MyProject.Data is supposed to deal with persistence, but I'm a little confused about how this is supposed to work. Am I supposed to be using Entity Framework to map my tables to the domain models? Should I do this with the Fluent API? Or am I supposed to be instantiating the model classes and populating them manually?

Upvotes: 4

Views: 2988

Answers (3)

David Masters
David Masters

Reputation: 8295

IMO you should not try to use your domain model objects as entity framework entities. You will not be able to craft properly encapsulated domain objects consisting of atomic methods. Instead they would need to have public properties with getters and setters that EF require, and this leads to an Anemic Domain Model.

Essentially: if you try to double up your domain objects as entity framework entities, you will compromise the design.

Instead, I employ something that loosely resembles the memento pattern, whereby I re-hydrate my domain objects with EF entities that serve as the "mementos". Vaugh Vernon calls these objects "state objects"

Given that EF can just use plain POCO's I'd put these classes in a different assembly to the assembly hosting your DbContext/Respositories, as your model will need to reference them. Because they are just POCO's you won't be tying your model to EF.

So you'd potentially have three assemblies:

  • MyProject.Model / MyProject.Core / MyProject.Domain ... which contains your DDD model classes & repository interfaces
  • MyProject.Infrastructure ... which contains DBContext, Repository Implementations & State objects

Example:

public class PersonRepository  : EntityFrameworkRepository, IPersonRepository
{
      public Person GetById(Guid personId)
      {
           using (MyDbContext ctx = new MyDbContext())
           { 
               var personState = (from p in ctx.People
                                   where p.PersonId == personId
                                   select p).FirstOrDefault(); 


               return Person.RestoreFromState(personState );

           }
      }
}

UPDATE

With EF Core you can now map to private fields so you might not need to add this level of complexity to keep the integrity of your design.

Also, I'd recommend the following post from Vaughn Vernon on the subject: https://kalele.io/modeling-aggregates-with-ddd-and-entity-framework/

Upvotes: 3

Paul T Davies
Paul T Davies

Reputation: 2573

The industry standard practice is to use some sort of Object/Relation Mapper such as Entity Framework or NHibernate etc to load and persist you entities.

O/RMs are tools for bridging the Impedance Mismatch between Object Oriented laguages and Relation Databases.

They are often combined with the Repository Pattern.

It is not essential to use these tool, you could manually save your entities to a database, or possibly build you own O/RM, but will will be creating yourself many unnecessary headaches. By using an O/RM tool, you will be gaining the benefit of many others experience in building DDD applications.

It is also worth poiting out that O/RM's are not only for DDD applications.

In my applications, the Data layer is usually a few repositories, the NHibernate mapping files and any other NHibernate implementation code.

Upvotes: 0

jgauffin
jgauffin

Reputation: 101150

The MyProject.Data is supposed to deal with persistence, but I'm a little confused about how this is supposed to work. Am I supposed to be using Entity Framework to map my tables to the domain models? Should I do this with the Fluent API? Or am I supposed to be instantiating the model classes and populating them manually?

Use what you know, or if allowed, what you want to learn.

Either way you should not leak any DB specific information back to the domain model or put any DB restrictions on the model.

Upvotes: 1

Related Questions