7

In Domain-Driven Design, the domain model should be completely unbeknownst of any data persistent specifics.

Let's say that an Employee belongs to a Department. The domain entities could look like this:

public Employee
{
    public string EmployeeId { get; set; }
    public string FirstName { get; set; }
    public string LastName{ get; set; }
    public Department Department { get; set; }
    public int DepartmentId { get; set; }
}

public Department
{
    public string DepartmentId { get; set; }
    public string Name{ get; set; }
}

Is Employee.DepartmentId really relevant in the domain model or is that an infrastructure storage detail?

Surely Employee.Department is the relationship that matters at this level?

In my case, these entities will be stored in a SQL database and the data will be retrieved by Entity Framework, so an Employee.DepartmentId column will exist in the database.

Dave New
  • 38,496
  • 59
  • 215
  • 394
  • The problem here is that you're re-using the primary key (a database concept) as the objects identity in the domain model. Entities should have a natural/surrogate identity defined in the model - this could be a guid for example. This would be used to query the repository. The database row id is just an implementation detail of the persistence platform. – MattDavey Dec 12 '13 at 10:52

1 Answers1

5

Life is easier in the Entity Framework if you use foreign keys:

Why does Entity Framework Reinsert Existing Objects into My Database?

Making Do with Absent Foreign Keys

And you are absolutely correct to say that the foreign key is not really relevant to the domain model. It is part of the persistence model.

So you need to decide which camp to join. Are you a purist or a pragmatist? Separate domain models and persistence models or not?

ORM Entities vs. Domain Entities under Entity Framework 6.0

Community
  • 1
  • 1
Colin
  • 22,328
  • 17
  • 103
  • 197
  • Why "not relevant" to the Domain Model? I can see why a FK specifically isn't appropriate since it's a persistence concern. But in the real world there's definitely a relationship between Employee & Department. A key tenet of DDD is reflecting the domain accurately in the model. So I'd expect to see something in the model to represent the relationship. Isn't the FK a derived artifact of the relationship? – sfinnie Dec 12 '13 at 11:39
  • apologies, I managed to miss the 'Department' property in the code. Without that I was missing how the rel would be modelled given lack of FKs. Makes sense now, sorry for the noise. – sfinnie Dec 12 '13 at 13:40
  • Whether it's easier or not is somewhat subjective. Certain aspects are easier in certain contexts, while others are harder. The need to attach existing entities tends to fall into a minority of situations these days, with Web applications comprising the largest share of .Net development. Use of a LoadEntity() extension method mitigates 99% of cases and allows for a cleaner and therefore more easily maintained domain model. – Derek Greer Feb 13 '20 at 16:43