DDD Mapping Entity Framework Data Model to Domain models

Question

I understand that Entity data models should be separated from real domain models, to avoid coupling between infrastructural concerns and domain itself, but i was wondering if all domain properties do not have public setters, how can we map from data model to domain model, especially if repository implementation resides in infrastructural part of project, so we can't use internal property setters.

class DomainModel
{
    string SomeProperty {get; private set:}
}

Pass parameters with constructor. But EF already IS repository pattern and unit of work, why do you need yet another abstraction based on that? Also, if you use code first, you don't need data model; just map database to domain model. — L-Four, Oct 25 '16 at 12:14
@L-Four what if 2 different domain models share same infrastructural table, or you require complex property within complex property? — Robert, Oct 25 '16 at 12:28
Then use techniques like "Entity Splitting". Not sure what you mean with complex property within complex property. — L-Four, Oct 25 '16 at 12:55
@L-Four Employee can have location, which can be complex type with address name, street number, zip code and geo_information, and geo_information can be another complex type, which means you need to have nested complex properties. I think entity framework does not support that, which means your domain model would be limited by infrastructural concerns. — Robert, Oct 25 '16 at 13:04
@L-Four Navigational properties are for (lazy) loading related information from another table. Can you map 1 flatted table in to entity with complex structure such as root class - complex type within root - complex type within complex type? — Robert, Oct 25 '16 at 13:51
Do you mean "Table Splitting" (http://www.c-sharpcorner.com/UploadFile/ff2f08/table-splitting-in-entity-framework-6-code-first-approach/)? — L-Four, Oct 25 '16 at 13:58
@L-Four no, not exactly. Imagine you have flatted table from old system which for some reasons cannot be split, and for performance reasons it's better to keep it as flat table. If you want to build a domain model like i described, you would have to change your infrastructure to suit your domain model and at that point you introduced infrastructure concerns to your domain, cause you will have to sacrifice infrastructure or design of your domain model. — Robert, Oct 25 '16 at 14:03
Well no, with table splitting you can map one existing table to a domain that has another format (multiple entities), right? Anyway, if that is not possible, you can still write a repository/data component that does it for that part? — L-Four, Oct 25 '16 at 14:04
@L-Four in the link you provided, could EmployeeDetails have one more complex property within in, other than relation back to employee? Maybe one more with PhoneNumber and Email (just an example) — Robert, Oct 25 '16 at 14:11
Like http://stackoverflow.com/questions/11018794/entity-framework-code-first-how-to-map-flat-table-to-class-with-nested-objects? — L-Four, Oct 25 '16 at 14:20
@L-Four more like this http://stackoverflow.com/questions/20332023/ef-6-nested-complex-type-in-another-complex-type — Robert, Oct 25 '16 at 14:21

score 2 · Accepted Answer · answered Oct 25 '16 at 12:11

In a schema where you have an intermediate "Data Model", Entity Framework no longer has control over how your domain entities are instantiated. Your Repository has. So they don't necessarily need public setters, you can also rehydrate them using the constructor.

One such technique is explained here : https://vaughnvernon.co/?p=879

Note that a simpler alternative can be to avoid the additional data model and use private setters (see https://lostechies.com/jimmybogard/2014/04/29/domain-modeling-with-entity-framework-scorecard/), if you consider the little impact EF will have on your entities a reasonable tradeoff.

score 0 · Answer 2 · answered Nov 10 '16 at 21:41

I understand that Entity data models should be separated from real domain models

Not true

avoid coupling between infrastructural concerns and domain itself

True

You CAN use EF to directly persist your domain models, however you should not couple your domain models to EF.

What does this look like?

Let's say you have a project called Domain which has your models in it, and another called DataStore which has your repositories to persist said models (using EF)

Now usually with EF you would use attributes and all sorts of nonsense on the models you want to persist, but this pollutes & couples those models to EF as a storage mechanism & adds dependancies to EF from your pure Domain project - this is what we are trying to avoid.

EF6 to the rescue, have a look at the EF6 FluentApi, you are able to configure your Domain models to work with EF without adding any EF specific attributes or dependancies to the Domain project.

Primary Key?

modelBuilder.Entity<OfficeAssignment>().HasKey(t => t.InstructorID);

Index?

modelBuilder 
.Entity<Department>() 
.Property(t => t.Name) 
.HasColumnAnnotation("Index", new IndexAnnotation(new IndexAttribute()));

Now this will quickly become a pain if you do this for each and every object, BUT if you stick to some conventions (or use a base type to make this even easier)

Then you can use reflection to do this auto-magically for all Entities in your domain.

Good luck

I'm a bit late, but how do you solve foreign keys in fluent api, when you do not want navigational properties pollute your domain model? — Robert, Nov 18 '16 at 12:27

DDD Mapping Entity Framework Data Model to Domain models

2 Answers2