Получение всех совокупных корневых сущностей дочерних сущностей?

Question

Я пытаюсь реорганизовать свое приложение из репозитория для каждой сущности в репозиторий для совокупного корня.

Базовым примером было бы то, что у меня есть корень сущности Cars. Автомобили имеют договора аренды. Насколько я понимаю, контракты не существуют без автомобилей, следовательно, автомобили - это общий корень.

Я пытаюсь реализовать пользовательское представление, которое будет отображать каждый контракт в системе (все дочерние объекты корневых объектов). Перед рефакторингом я мог просто зайти в свой репозиторий контрактов и получить все. Поскольку хранилище контрактов было удалено (поскольку оно не является корневым), теперь мне нужно вытащить все машины из моего хранилища и затем получить все их контракты.

Мой репозиторий имеет интерфейс

public interface ICarRepository
{
    IQueryable<Car> All { get; }
    IQueryable<Car> AllIncluding(params Expression<Func<Car, object>>[] includeProperties);
    Car Find(long id);
    void InsertOrUpdate(Car car);
    void Delete(long id);
    void Save();
}

Я думал о создании ICarManagementService и наличии у него метода GetAllContracts (возможно, с параметрами фильтра). Означает ли это, что для получения всех контрактов мне нужно вытащить все автомобильные объекты со своими контрактами, а затем извлечь связанные с ними договоры найма и отфильтровать их?

Затем я могу передать их контроллеру и автоматически оформить контракты, как и раньше.

Это лучшая практика?

Спасибо

Graeme

Answer 1

Насколько я понимаю, контракты не существуют без автомобилей, следовательно, автомобили - это общий корень.

Это не обязательно так.«Не существует без» недостаточно для того, чтобы сущность стала частью совокупного корня.Рассмотрим классический домен обработки заказов.У вас есть Орден, который является Совокупным Корнем.У вас также есть Клиент, который является Совокупным Корнем.Заказ не может существовать без Клиента, но это не означает, что Заказы являются частью Агрегата Клиентов.В DDD сущности внутри одного агрегата могут иметь ссылки на другие агрегатные корни.Из DDD book :

Объекты в AGGREGATE могут содержать ссылки на другие корни AGGREGATE.

Aggregate - это единица жизненного цикла и обмена данными.По сути, это кластер объектов, который применяет инварианты.Это то, что вы хотите заблокировать, если у вас есть несколько пользователей, которые меняют домен одновременно.

Возвращаясь к вашему вопросу, я понимаю, что домен - это что-то вроде аренды / аренды автомобиля / грузовика / лимузина /бульдозер.Я думаю, что HireContract, возможно, не является частью совокупности автомобилей, потому что они могут иметь разные жизненные циклы, и HireContract имеет смысл сам по себе, без автомобилей.Кажется, что это скорее отношение Заказ-Продукт, которое также является классическим примером двух разных Агрегатов, ссылающихся друг на друга.Эта теория также подтверждается тем фактом, что бизнес должен видеть «Все контракты».Они, вероятно, не думают об автомобиле, содержащем все контракты.Если это так, то вам нужно сохранить свой ContractsRepository.

На несвязанной заметке вас может заинтересовать чтение этого ответа о дизайне интерфейса репозитория.

Answer 2

Отделяйте концепцию чтения / запроса от команды записи /, поскольку в соответствии с CQRS предпочтительно разрабатывать приложение, разделяя модель чтения, которая состоит из запросов только для чтения, и модель записи, с другой стороны, которая состоит из команд для выполнить определенную логику на доменной модели.

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

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

check (http://moh -abed.com / 2011/09/13 / pure-old-ddd-with-a-twist-from-cqrs /) и (http://simon -says-architecture.com / 2011 / 08/23 / хранилище)