Обработка изменений внутри агрегата с отдельным уровнем домена и уровня стойкости - PullRequest
Новая
       84

Обработка изменений внутри агрегата с отдельным уровнем домена и уровня стойкости

1 голос
/ 06 мая 2020

Я новичок в DDD, но я стараюсь втиснуть как можно больше как можно быстрее. Я использовал https://github.com/dotnet-architecture/eShopOnContainers в качестве руководства по структурированию моего кода с помощью Mediatr и EF Core.

К счастью для этого приложения, персистентность и модель предметной области одинаковы. К сожалению, для меня мой уровень данных не соответствует нашей модели предметной области, так как это устаревшая база данных.

Итак, я отделяю домен от постоянства, что хорошо и хорошо. Но мне трудно понять, где, если я сделаю этот блок кода в обработчике команд (пытаясь сделать его простым и понятным) ... 

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

Как я могу вызвать базовый контекст базы данных для репо, чтобы быть в курсе примененных изменений. Единственное, что я могу придумать, - это иметь вызов repo.Update (агрегатный), который затем будет пытаться применить вызовы db для обновления различных мест db.

Мне это кажется запахом.

Любые идеи были бы замечательными.

Спасибо!

Изменить: должен ли шаблон репозитория с отдельным доменом и уровнем постоянства возвращать модель уровня пресистентности или модель домена?

Например: у меня есть совокупная Компания. И у меня есть таблица базы данных под названием CompanyLegacy, которая моделируется на уровне постоянства с использованием ядра структуры сущностей.

Должен ли мой репозиторий быть CompanyLegacyRepository или CompanyRepository? Если CompanyRepository, это будет означать, что я запрашиваю таблицу CompanyLegacy и сопоставляю ее с моделью домена компании, а затем возвращаю ее. Эта модель не подлежит отслеживанию. Вот откуда моя проблема.

Но если я должен использовать CompanyLegacyRepository, то, похоже, это не соответствует рекомендациям DDD, в которых все действия должны применяться к совокупности root.

1 Ответ

1 голос
/ 06 мая 2020

Должен ли шаблон репозитория с отдельным доменом и уровнем персистентности возвращать модель уровня персистентности или модель домена?

Репозиторий должен возвращать вашу модель домена. Если вы используете DTO (например, CompanyLegacy) на уровне инфраструктуры, то ваш репозиторий несет ответственность за сопоставление их с моделями вашего домена. Обратите внимание, что в многоуровневой архитектуре уровень приложения не должен знать о DTO, используемых на уровне инфраструктуры ... это ваши модели домена, которые являются сердцем вашего приложения. См. этот вопрос , который тесно связан с вашим.

Ваш репозиторий должен называться CompanyRepository. Вы можете определить интерфейс для этого репозитория, например: 

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);
}

Отслеживание изменений

Отслеживание изменений Entity Framework имеет свои ограничения, этот вопрос является примером одного из этих Disconnected Scenar ios, где мы не можем полагаться на отслеживание изменений EF (из-за DTO). Реализация указанного выше репозитория будет выглядеть следующим образом: 

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();
    }
}

Этот учебник полезен для более сложных операций, и вы можете найти дополнительную информацию об отслеживании изменений EF Core здесь .

этот ответ относится к EF 4/5/6 (не к ядру), но дает вам некоторое представление об использовании уникального идентификатора, чтобы решить, следует ли добавлять или обновлять сущность.

...