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?"


3 Answers 3


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.

  • "I would also consider returning your EF entities to the application layer" The current design does that exactly, the application layer then converts this to DTO and passes it on to UI. I am trying to learn DDD by refactoring an existing application so that it is close to real world. Commented Aug 28, 2015 at 0:00
  • @SriHarshaVelicheti okay, but your refactor is going to introduce yet another layer of objects. I'm not sure if that is acceptable for the real world. Commented Aug 28, 2015 at 15:58
  • You don't particularly need lazy loading for this. Eager loading can be equally selective about which relations get loaded and which don't (e.g. you can load all of a contract's sites without loading all the contractors of those sites). I'm mentioning this because in sizeable codebases, lazy loading becomes a slog to work with and a source of unexpected bugs.
    – Flater
    Commented Dec 3, 2019 at 16:41

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.

  • In my model Site in itself is an Entity, same Site (location) can be shared by multiple contractors, and a Contractor can have multiple sites associated to them. So should Site be an Aggreate Root? And I think then Contractor will also be a Aggregate root? Commented Aug 27, 2015 at 19:41
  • Yes. Both will be aggregate roots. Commented Aug 28, 2015 at 5:25
  • Ok, If I model both of these as aggregate roots, where will the logic of associating a site to a contractor reside in? Should it be handled by Domain services or Should it be in Site\Contractor aggregate roots? Commented Aug 28, 2015 at 21:02
  • Yes you should choose one of aggregate roots to enforce the constraints of the association. Commented Aug 29, 2015 at 7:15

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.

  • I'm fairly confident "contract" in this case is more like the term that this contractor will be available and so probably doesn't need to be handled as a separate business object Commented Aug 27, 2015 at 1:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.