How to update grandchildren in an aggregate root

Question

I Use EF Code First, and lazy loading.

My problem relates to how to efficiently update an entity in within a grandchild collection. First of all, i fear this makes a lot of calls in the db that is not really needed. But if my domain class is not to care about persitance, I cant see another way to do this.

Here is the classes:

  public class Supplier
 {
  public int Id {get;set;}
  //...Supplier properties

  public virtual ICollection<Contract> Contracts {get;set;} 

  //supplier methods   
 }

 public class Contract
 {
  public int id {get;set;}
  public int SupplierId{get;set;}
  //---Contract properties

  [ForeignKey("SupplierId")]
  public virtual Supplier Supplier {get;set;}
  public virtual ICollection<DeliveryContract> DeliveryContracts {get;set;} 
 }

 public class DeliveryContract
 {
  public int Id {get;set;}
  public bool DeliveryOnMonday{get;set;}
  public bool DeliveryOnTuesday{get;set}
  //...30 different Delivery terms properties

  public Department Department {get;set;}

  public int ContractId {get;set;}
  [ForeignKey("ContractId")
  public virtual Contract Contract {get;set;}
 }

The Supplier is the aggregate Root. So i have a method on the supplier which is ChangeDeliveryContract, and that corresponds to what would happen in the real world.

public class Supplier
{
 //properties

 public void ChangeDeliveryContract (DeliveryContract cahangedDc)
 {
   //So from the supplier i have to find the contract to change
   var dcToUpdate = Contracts
                    .SingleOrDefault(c=>c.Id == changedDc.ContractId)
                    .SingleOrDefalut(dc=>dc.Id == changedDc.Id);

   //So... what do i do now? Map all 30 properties from changedDc to DcToUpdate
   //Some business rules is also applied here i.e. there can only be one
   // DeliveryContract between Supplier and Department
 }
}

I use MVC so the program would look something like: public ActionResult Update (DeliveryContract changedDc, int supplierId)

{
  var Supplier = supplierRepository.GetById(supplierid);
  supplier ChangeDeliveryContract (changedDc);
  supplierRepository.Save();

  //More code...
}

First of all, the problem lays in the ChangeDeliveryContract. I've not been able to get this to work. Also, i feel querying through collections like I do might be inefficient. Third, mapping 30 + properties also feels a bit wrong.

How do you guys do it, and is there a best practices here.

Answer 1

In applying DDD, the selection of aggregate roots can vary depending on various characteristics of the model, which include considerations regarding the number of children, etc. In this case, while Supplier is an AR, it does not mean that DeliveryContract can't also be an AR. While it may seem like Supplier is the sole AR and all operations regarding suppliers should stem from the Supplier class, this can become unruly with respect to database calls as you've come to realize. One role of an AR is the protection of invariants and there is nothing on the Supplier class that is used to protecting invariants which is a possible indication that Supplier is not the most appropriate AR to implement the required business rules. Therefore, it seems to me that in this case you can make DeliveryContract an AR, with its own repository, and a method for applying changes. Or you can make Contract an AR, depending on whether a contract must enforce any invariants regarding delivery contracts and also on a practical consideration of the number of expected delivery contracts per contract. If the number is very high, then it would be impractical to have a collection of delivery contracts on the contract class. Overall, I would opt for having smaller ARs, though invariants and consistency rules must be considered.

Take a look at a great series of articles by Vaughn Vernon for an in-depth treatment of this topic: Effective Aggregate Design.

Answer 2

OK, this is a bit confusing and I blame it on the mixing of the Domain and Persistence models(yeah, those EF tutorials have done a GREAT job of confusing everyone). One should not influence another, that's why you have the repository pattern. And yes, the domain should not care about the persistence.

Now that the Suplier doesn't know about EF anymore, let'see... If I understand correctly then you prety much need to redesign the Supplier (and probably the children aggregates as well) because you need to take into account the business rules.

It's pretty hard for me to reverse engineer the requirements from that code, but I have a feeling that a supplier has delivery contracts to different departments. When you change a delivery contract the supplier should enforce the business rules valid in that context (that's important if there are multiple contexts valid for the same entity).

I think though the delivery contract needs a bit more clarification, because I can't believe it's only a dumb object that only holds 30 properties. Perhaps some business rules are tied to some properties? So, we need more details.

As a side, if your really need to map 30 properties brcause that's the way it is, you can use Automapper for that.

Answer 3

About the property mapping in ChangeDeliveryContract, you feel like mapping 30 properties is a bit wrong. In itself there's nothing wrong with mapping 30 properties. If it has to be done, it has to be done. You could use AutoMapper for it, to ease the task.

I think the 'feel' of the code can be changed if you make methods like 'Supplier.MakeDeliveryOnMonday()', 'Supplier.DontMakeDeliveryOnTuesday()'. You probably can guess what these methods do (check business logic and set a boolean to true or false). So you don't have to use 'big' methods like ChangeDeliveryContract.