Получаване на всички обобщени коренни обекти дъщерни обекти?

Опитвам се да преработя приложението си от хранилище за обект в хранилище за сборен корен.

Основен пример би бил, че имам корен на обект на Cars. Автомобилите имат договори за наем. Доколкото виждам, договорите не съществуват без автомобили, следователно автомобилите са обобщеният корен.

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

Моето хранилище има интерфейса

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 (може би с параметри на филтъра). Това би означавало, за да получа всички договори, от които се нуждая, да извадя всички автомобилни субекти с техните договори и след това да извлека договорите за наем на всеки субект, свързани с тях, и да ги филтрирам?

След това мога да ги предам на контролера и AutoMap на договорите, както преди.

Това ли е най-добрата практика?

Благодаря

Греъм


person GraemeMiller    schedule 18.09.2011    source източник


Отговори (2)


Доколкото виждам, договорите не съществуват без автомобили, следователно автомобилите са обобщеният корен.

Това не е непременно вярно. „Не съществувам без“ не е достатъчно, за да може даден обект да стане част от Съвкупен корен. Помислете за класически домейн за обработка на поръчки. Имате поръчка, която е обобщен корен. Имате и клиент, който е обобщен корен. Поръчката не може да съществува без Клиент, но това не означава, че Поръчките са част от Клиентския агрегат. В DDD обектите вътре в един Aggregate могат да имат препратки към други Aggregate Roots. От DDD книга:

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

Aggregate е единица за жизнен цикъл и обмен на данни. По същество това е клъстер от обекти, който налага инварианти. Това е нещо, което искате да бъде заключено, ако имате няколко потребители, които променят домейна едновременно.

Обратно към въпроса ви, моето разбиране е, че домейнът е нещо като наем / лизинг на кола / камион / лимузина / булдозер. Мисля, че HireContract може да не е част от агрегата Car, защото те може да имат различни жизнени цикли и HireContract просто има смисъл сам по себе си, без Car. Изглежда, че това е по-скоро връзка Поръчка-Продукт, която също е класически пример за два различни агрегата, препращащи един към друг. Тази теория се потвърждава и от факта, че бизнесът трябва да види „Всички договори“. Те вероятно не мислят за кола, съдържаща всички договори. Ако това е вярно, трябва да запазите своето ContractsRepository.

По несвързана бележка може да ви е интересно да прочетете този отговор относно интерфейса на хранилището дизайн.

person Dmitry    schedule 18.09.2011
comment
Мислех, че искам хората да могат да заключват Cars за редактиране. Мога да видя договорите за наем като съвкупност. Трябва да попреча на хората да могат да добавят припокриващи се периоди на наемане. Мога ли все пак да наложа, че if hires е съвкупност. - person GraemeMiller; 18.09.2011
comment
Трудно е да се отговори на този въпрос, без да имате добро разбиране на вашия домейн. Но мога да ви подскажа. Има метод, споменат от Уди Дахан и/или Грег Йънг, който трябва да опитате да си представите как тази функционалност ще бъде приложена в „хартиен“ бизнес, без компютри. Това може да доведе до по-асинхронен подход (позволяването на временно припокриване на периода на наемане, както Amazon позволява на двама клиенти да поръчат книгата, дори ако само 1 е останал на склад, и след това ви уведомява по имейл). Много може да се постигне, ако премахнете всичко трябва да бъде 100% последователно, цялото времево ограничение. - person Dmitry; 20.09.2011
comment
Евентуално ще публикувам по-подробен въпрос по-късно. Моят екземпляр от синята книга трябва да пристигне тази седмица, така че се надявам да се справя по-добре с добрата DDD практика. Благодаря за помощта. - person GraemeMiller; 21.09.2011

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

по този начин заявките за всички обобщени корени или създаването на персонализирани заявки за свързване на набори от данни не е добър кандидат за хранилище на домейн, вместо това поставете тези заявки в хранилище за четене (или по-добре наречени Finders).

ако установите, че искате да направите заявка за колекция от обекти, за да изпълните някаква домейн логика, това е индикатор, че трябва да абстрахирате тази колекция и да я поставите в обобщен корен, за да ги капсулирате и да накарате бизнес операцията или метода да действа върху тях .

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

person Mohamed Abed    schedule 18.09.2011
comment
Тези връзки са мъртви, добре е да цитирате съществените части в отговора. За щастие, стари моментни снимки присъстват в https://web.archive.org/web/20150531070309/http://moh-abed.com/2011/09/13/pure-old-ddd-with-a-twist-from-cqrs/ и https://web.archive.org/web/20160403195814/http://simon-says-architecture.com/2011/08/23/repository/ - person kravemir; 16.01.2021
comment
Това обаче е добър отговор. Съвкупните корени на DDD всъщност се отнасят само до обхвата на изпълнение/промяна на командата,.. Но има различни опасения за преглед само за четене, където няма смисъл да се мисли в обобщени корени, напр. обобщени заявки за статистика, отчети, елементи на таблото за управление... - person kravemir; 16.01.2021