вступление
Этот вопрос касается DDD и источника событий, где объекты в составе агрегата, отличного от агрегированного корня, имеют поведение, генерирующее события.
Пример
Далее следует пример описываемой мной ситуации, в которой я уверен, что хочу инкапсулировать некоторую логику внутри других сущностей внутри Aggregate. Это может означать приостановку недоверия к реальному примеру и тому, является ли он хорошей моделью или нет. :)
Я пытаюсь смоделировать DeliveryRun
агрегатный корень (AR), который представляет собой поездку, которую совершает транспортное средство для выполнения доставки. Перед отправкой необходимо обновить DeliveryManifest
. «Актуальность» этого подсказывает мне, что DeliveryManifest
будет сущностью в пределах DeliveryRun
границы согласованности, определенной AR.
Ладно пока.
Я использую для этого подход Event Sourcing - подход, которому научил Greg Young и реализован в библиотеке Regalo. Это означает, что AR (DeliveryRun
) фактически не должен иметь никаких сущностей, если для них нет поведения (например, SalesOrder
может не иметь SalesOrderLines
, потому что вместо этого он записывает такие события, как _8 _ / _ 9_).
Однако в отношении DeliveryManifest
должна быть некоторая логика. В частности, после первого запроса манифеста при добавлении элементов в доставку необходимо создать новую версию манифеста. Это означает, что мы можем гарантировать, что водители не уезжают, пока не будет доступен самый последний манифест.
Если бы мне пришлось инкапсулировать логику внутри объекта DeliveryManifest
(который не будет сериализован и сохранен; мы используем Event Sourcing, а не AR), как мне фиксировать события?
Варианты, которые я рассматриваю
Должны ли события генерироваться объектом
DeliveryManifest
, но сохраняться для самогоDeliveryRun
(которому тогда нужно знать, как воспроизвести эти события вDeliveryManifest
при загрузке из хранилища событий)?Должно ли быть не
DeliveryManifest
(кроме, возможно, структуры данных), и вся логика / события должны быть реализованы непосредственноDeliveryRun
?Должен ли
DeliveryManifest
быть его собственным AR и убедиться, чтоDeliveryRun
сообщает идентификатор текущего манифеста? Поскольку это выводит объект манифеста за пределы согласованностиDeliveryRun
, мне нужно будет создать некоторую обработку событий, чтобы подписаться на изменения вDeliveryRun
, которые имеют отношение к манифесту, чтобы его можно было обновить / сделать недействительным и т. Д. Соответственно.Реализуйте другой стиль для захвата событий, аналогичный шаблону Udi DomainEvents. Это означает изменение библиотеки Regalo, хотя я думаю, что ее можно довольно легко сделать для поддержки обоих шаблонов. Это позволит захватывать все события, генерируемые всеми объектами в совокупности, чтобы их можно было сохранить для AR. Мне нужно было подумать о решении для загрузки / воспроизведения, хотя ...