Should we include all relationships in the domain entity?

Question

I have a question on modelling an Entity\Aggregate root in DDD. I am refactoring a project that uses Entity Framework and business logic as services, the services contain lots of logic which I believe should be in entities in DDD.

public class Contractor
{
   public int Id {get;set;}
   public DateTime ContractStartDate {get;set;}
   public DateTime ContractEnddate {get;set;}
   public string PhoneNumber {get;set;}
   public Address Address {get;set;}
   /*Bunch of other properties */
   public ICollection<Site> ContractorSites {get;set;}
}
public class Site
{
   public int Id {get;set;}
   /*Bunch of other properties */
}

Now I am trying to model the Contractor as an Entity. The problem I am facing is with the ContractorSites property. A contractor can have one or more sites associated to him.

Now when I am modelling a contractor as an Entity, should I include this property? If I include this does this mean that every time I want to fetch a contractor's details from the database and create this entity, I will have to fetch the related sites as well?

My question boils down to "should we include all relationships in the domain entity?"

Answer 1

A contractor can be assigned to several sites.

A site can have multiple contractors assigned to it.

When you fetch sites for a contractor, will you also fetch each site's associated contractors? And will you then fetch their sites?

Letting the lazy evaluation and reference resolution already implemented in EF do the work for you really pays dividends in terms of time saved. Implementing these relationships by hand in your domain layer over top of Entity Framework is a lot of work for little benefit.

Instead of struggling to answer this question now, I would hold off and let a pattern emerge that shows what kind of relationships are frequently required by your app, or alternatively, wait for a (non-refactor-induced) problem to emerge that requires a tweak to existing design.

I would also consider returning your EF entities to the application layer unless you have a really good reason not to. Although your entities become somewhat cross-cutting concerns, the work required to reimplement and map objects across application layers (especially if there is little to no reuse by other applications) may not be worth it.

Answer 2

According to Vaughn Vernon it is best to use entity framework as state objects when designing aggregates when designing aggregates because they are inflexible compared to other ORMs.

With that in mind. Why are you starting with entities? In DDD you need an aggregate root to maintain the consistency boundary. An aggregate root may have entities and value objects.

To address your question. Unless Site is a value object you cannot share a site between multiple contractors. If multiple contractors could logically belong to the same site you need to either make Site an aggregate root and then only store the ID. Or see it as an immutable value object and just store the same copy under multiple aggregates.

Answer 3

In general, you need more concepts and more relationships between them, or you'll have problems as your modeling expands.

For one, it seems to me that you are missing a notion of Contract. The notion of start date and end date relate more to the specific contract rather than the contractor (the contract then relates to the contractor). I think you should make Contractor, Contract, Contract Site all as separate entities -- there may be a single aggregate root for starters, but I suspect you'll eventually make some of these separate roots as well.

Also, you should allow for multiplicities in Contact Information, meaning they should probably also be separated.