CODEWITHSUNDEEP
c#entity-framework-coredomain-driven-designrepository-pattern
Matthew Hartz
Matthew Hartz

Reputation: 271

Handling Changes Inside Aggregate with Separate Domain and Persistance Layer

I'm fairly new to DDD but I am trying to cram as much as possible as fast as possible. I followed https://github.com/dotnet-architecture/eShopOnContainers as a guide for how to structure my code with Mediatr and EF Core.

Fortunately for this application, the persistence and domain model are the same. Unfortunately for me, my data layer does not match our domain model as it is a legacy db.

So i am separating the domain from persistence which is well and good. But I am having a hard time understanding where if i do this code block in a command handler(trying to make it simple and clear)...

var aggregate = repo.GetById(1234);
aggregate.AddItemToList(item);
repo.SaveChanges();

How can i cause the underlying database context of the repo to be aware of the changes that were applied. Only thing i can think is to have a repo.Update(aggregate) call, that would then try to apply db calls to update various places of the db.

This seems like a smell to me.

Any insights would be great.

Thank you!

Edit: Should the repository pattern with a separate Domain and Persistence layer return the presistance layer's model or the domain's?

For example: I have a aggregate Company. And i have a database table called CompanyLegacy which is modeled in the persistence layer using entity framework core.

Should my repository be CompanyLegacyRepository or CompanyRepository? If CompanyRepository, that would mean i query the CompanyLegacy table, and map it to a Company domain model then return it. This model, would not be change tracked. This is where my issue comes from.

But if I'm supposed to do a CompanyLegacyRepository then it seems like that doesn't adhere to DDD guidelines where all actions to be applied to the aggregateroot.

Upvotes: 1

Views: 1432

Answers (1)

Hooman Bahreini
Hooman Bahreini

Reputation: 15559

Should the repository pattern with a separate Domain and Persistence layer return the persistence layer's model or the domain's?

Repository should return your Domain model. If you are using DTOs (such as CompanyLegacy) in your Infrastructure layer, it is the responsibility of your Repository to map them to your Domain models. Please note that in a Layered Architecture, the Application layer is not supposed to know about the DTOs used in the Infrastructure layer... it's your Domain models which are the heart of your application. See this question which is closely related to yours.

Your Repository should be called CompanyRepository. You can define an interface for this repository like:

public interface ICompanyRepository
{
    // Company is your domain model not DTO (i.e. your legacy model)
    Company GetById(int id);
    void Add(Company);
    void Update(Company);
}

Change Tracking

Entity Framework change tracking has it's limitations, this question is an example of one of those Disconnected Scenarios, where we cannot rely on EF Change Tracking (because of DTOs). The implementation of the above repository would be like:

public CompanyRepository: ICompanyRepository
{
    Private MyDbContext _context;
    public CompanyRepository(MyDbContext myDbContext) { _context = myDbContext; }

    public Company GetById(int id)
    {
        var companyLegacy = _context
            .CompanyLegacy
            .AsNoTracking()
            .Where(c => c.id = id)
            .FirstOrDefault();
        return MyMapper.ToCompany(companyLegacy);
    }

    public void Add(Company company)
    {
        var companyLegacy = MyMapper.ToLegacy(company);
        _context.Add(companyLegacy);
        _context.SaveChanges();
    }

    public void Update(Company)
    {
        var companyLegacy = MyMapper.ToLegacy(company);
        _context.Update(companyLegacy);
        _context.SaveChanges();
    }
}

This tutorial is helpful for more advanced operations and you can find more info about EF Core change tracking here.

this answer is related to EF 4/5/6 (not core) but gives you some idea about using unique identifier to decide if an entity should be Added or Updated.

Upvotes: 2

Related Questions