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 lot 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 Contractor as 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 an contractor as Entity, should I include this property? If I include this does this mean that every time I want to fetch a contractor details from database and create this entity (, i will have to fetch the related sites as well?

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

  • I wonder if someone's drawn a relation ship, just like the alot. – immibis Aug 27 '15 at 1:41
  • Change the question title. – Matthew James Briggs Aug 30 '15 at 5:26

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. – Sri Harsha Velicheti Aug 28 '15 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. – moarboilerplate Aug 28 '15 at 15:58

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? – Sri Harsha Velicheti Aug 27 '15 at 19:41
  • Yes. Both will be aggregate roots. – Esben Skov Pedersen Aug 28 '15 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? – Sri Harsha Velicheti Aug 28 '15 at 21:02
  • Yes you should choose one of aggregate roots to enforce the constraints of the association. – Esben Skov Pedersen Aug 29 '15 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 – moarboilerplate Aug 27 '15 at 1:32

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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