въведение
Този въпрос е относно DDD и източник на събития, където субектите в рамките на Aggregate, различни от Aggregate Root, имат поведение при генериране на събития.
Пример
Това, което следва, е пример за ситуацията, която описвам, където съм сигурен, че искам да капсулирам някаква логика в други обекти в рамките на агрегата. Това може да включва спиране на неверието по отношение на действителния пример и дали той е добър модел или не. :)
Опитвам се да моделирам DeliveryRun
Съвкупен корен (AR), което е пътуването, което превозното средство прави, за да извърши доставка. Преди да тръгне, трябва да има актуален DeliveryManifest
. „Актуалността“ на това ми подсказва, че DeliveryManifest
е обект в рамките на границата на последователност DeliveryRun
, дефинирана от AR.
Добре засега.
Използвам подход за източник на събития за това - подходът, както се преподава от Greg Young и имплементиран в библиотеката Regalo. Това означава, че AR (DeliveryRun
) всъщност не трябва да има никакви обекти, ако няма поведение за тях (напр. SalesOrder
може да няма SalesOrderLines
, защото вместо това записва събития като ItemsAdded
/ItemsRemoved
).
Все пак трябва да има някаква логика около DeliveryManifest
. По-конкретно, след като манифестът е заявен за първи път, когато елементите се добавят към доставката, трябва да се създаде нова версия на манифеста. Това означава, че можем да гарантираме, че шофьорите няма да потеглят без най-актуалния наличен манифест.
Ако трябваше да капсулирам логиката вътре в обекта DeliveryManifest
(който няма да бъде сериализиран и съхранен; ние използваме Event Sourcing и това не е AR), как да заснема събития?
Варианти, които обмислям
Трябва ли събитията да се генерират от
DeliveryManifest
обекта, но да се записват срещу самияDeliveryRun
(който след това ще трябва да знае как да възпроизвежда тези събития вDeliveryManifest
, когато се зареди от хранилището за събития)?Трябва ли да няма
DeliveryManifest
(освен може би като структура от данни) и цялата логика/събития да се изпълняват директно отDeliveryRun
?Трябва ли
DeliveryManifest
да бъде негов собствен AR и да се уверите, чеDeliveryRun
е уведомен за идентификатора на текущия манифест? Тъй като това извежда обекта на манифеста извън границата на съгласуваност наDeliveryRun
, ще трябва да създам някаква обработка на събития, за да се абонирам за промени вDeliveryRun
, които са от значение за манифеста, така че да може да бъде съответно актуализиран/невалиден и т.н.Приложете различен стил за улавяне на събитията, подобен на модела DomainEvents на Udi. Това означава промяна на библиотеката Regalo, въпреки че мисля, че може да се направи така, че да поддържа и двата модела доста лесно. Това би позволило всички събития, генерирани от всички обекти в агрегата, да бъдат уловени, така че да могат да бъдат запазени срещу AR. Все пак трябва да измисля решение за зареждане/възпроизвеждане...