Следует ли избегать агрегатов (DDD) в системе без хранилища событий?

Question

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

Я еще не закончил читать синюю книгу, но мое понимание корневого агрегата до сих пор состоит в том, что это «дерево» агрегатов, которое должно быть согласованным в этом корневом агрегате. Агрегат может быть изменен только через корневой агрегат, к которому он принадлежит. Наконец, корень в основном можно определить как «имеет ли смысл иметь этот агрегат независимым и может ли он существовать сам по себе в этом домене?».

Представьте себе проект «зеленого поля», в котором пока нет смысла проектировать источники событий, но он может извлечь из этого пользу в будущем. Отсутствие хранилища событий исключило бы возможность отслеживать все события домена, формирующие корневую совокупность в определенный момент времени. Команды должны будут изменить корневую совокупность. Кроме того, сторона чтения будет ограничена, чтобы реагировать на «корневой агрегат {id} обновлен», поскольку нет возможности воспроизведения событий.

Существует ли какой-либо разумный способ существования концепции (корневых) агрегатов без хранилища событий, или следует придерживаться "традиционного" моделирования сущностей, пока не имеет смысла инвестировать в источник событий?

Answer 1

Я верю, что вы путаете вещи.Не существует такого понятия, как корневой агрегат или дерево агрегатов.

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

Агрегат может состоять из нескольких типов объектов.Однако только один тип сущности служит совокупным корнем .Идентификатор корня агрегата является идентификатором для всего агрегата.Другие сущности внутри агрегата будут иметь свои идентификаторы (в противном случае это не сущности, а объекты-значения), но эти сущности нельзя изменять или ссылать непосредственно из-за пределов агрегата, и все операции со всеми сущностями внутри одного агрегата выполняются в корне агрегата.

Наиболее типичным примером агрегата является Order, где Order сам (или OrderHead, если хотите) является корнем, а OrderLine - сущностью.Вы можете иметь несколько строк заказа для одного заказа, но все операции в любой строке проходят через корень.

Нет прямой и явной связи между совокупным шаблоном и источником событий.Event-Sourcing - это детали реализации.В книге Эрика Эванса даже не упоминается источник событий как таковой, и в нем довольно много примеров агрегатов.

Источник событий - это способ сохранения данных.Фактически, получение событий полностью не связано с DDD, хотя Грег Янг изначально предлагал использовать получение событий как способ сохранения агрегатов путем хранения событий домена.

Когда у вас есть модель чистого домена, она недействительно важно со стороны модели предметной области, какой механизм сохранения вы используете.Многие системы, основанные на событиях, вообще не имеют понятия совокупности.Например, New York Times создала систему управления контентом, основанную на событиях, без учета тактической схемы DDD.С другой стороны, большинство систем, использующих тактические шаблоны DDD, не используют источники событий и используют только постоянство на основе состояния.