DDD 和实体框架

Question

I'm looking to use DDD in an application with EF as the data access layer. Most of what I've read has suggested separating the domain model classes with the data classes, which makes sense to me and keeps the domain cleaner. I'm running into an issue with going from domain layer to persistence layer.

Say in my domain I have the following 3 classes:

class Root 
{
   int RootId { get; }

   IReadOnlyCollection<Child> Children { get; }

   Child AddNewChild(IReadOnlyCollection<Data> data) {
      // Validate, create, and add child to internal list
      // Then what?
   }

   // More irrelevant properties/methods
}

class Child 
{
   // This has a LOT of entries
   IReadOnlyCollection<Data> Data { get; }

   // More irrelevant properties/methods
}

class Data 
{
   decimal Value { get; }

   // More irrelevant properties/methods
}

The EF data classes would be very similar, but implemented in a way EF is happy with.

Root in this case is my aggregate root, with the others being entities\value objects contained in the aggregate, so I would have an IRootRepository in order to query, add, and remove Root entities implemented with EF.

One issue is how does the Root.AddNewChild() method persist the data with this? My understanding is that the user code would get a unit of work (implemented via DbContext ), use that to access the IRootRepository to load a Root , and then call Root.AddNewChild() , but without Root being an EF object there isn't a way to track that on the persistence level. I've considered making Root an abstract class and adding the persistence stuff in there by inheriting from Root with my EF data class, but this seems wrong. I've also considered domain events, but is that too flimsy or is communicating with persistence layer what they are for?

The other issue has to do with the Child.Data property which will have a lot of entries. I don't want to pull every Data object from the database when loading my aggregate root for performance reasons, but I don't see a way of returning that data after loading the Root without somehow going through the persistence layer. I could create an IDataRepository for that, but then Child would have a dependency on it which seems odd and also it violates the DDD "one repository per aggregate" guidelines.

It seems like beyond very basic scenarios this format falls apart. Am I missing something on how to structure all of this? Should those problem methods fall to the repository or some other service?

Thank you for your help!

Answer 1

The Root.AddNewChild() method does not call anything to store the state in the database. Storing the state is an infrastructure matter and the domain layer should be persistence ignorant. Storing the state is actually a feature of the repository, and the repository is the one to know about the unit of work:

public class AddChildToRootService
{
  private readonly IRootRepository rootRepository;

  public async Task AddChildToRootAsync(IReadOnlyCollection<Data> values, int rootId)
  {
    var root = await rootRepository.GetByIdAsync(rootId);
    root.AddNewChild(values);
    await rootRepository.UpdateAsync(root);
  }
}

public class RootRepository : IRootRepository
{
  private readonly IMapper mapper;
  private readonly DbContext context;

  public async Task<Domain.Root> GetByIdAsync(int id)
  {
    return await context.Roots
      .Where(root => root.Id == id)
      .ProjectTo<Domain.Root>(mapper.ConfigurationProvider)
      .FirstOrDefaultAsync();
  }

  public async Task UpdateAsync(Root root)
  {
    var entity = await context.Roots
      .Where(entity => entity.Id == root.RootId)
      .FirstOrDefaultAsync();

    // reverse mapping here

    await context.SaveChangesAsync();
  }
}

Regarding Child.Data , you are allowed to make multiple domain model that overlap, with different level of details. This is called a polysemic domain model . In that situation, you can have a RootRepository , that manipulates Root and Child aggregate, and a RootDataRepository , that manipulates RootData , ChildData , and Data aggregate. All models and repository map to the same persistence tables but are considered two different root aggregates at the domain layer, each with their own domain model and repository. Then you may use the RootDataRepository in use cases that need the Data level of details, and the RootRepository in use cases that do not need them.