DDD: объект с коллекцией объектов-значений - одно событие или несколько? - PullRequest
Новая
       37

DDD: объект с коллекцией объектов-значений - одно событие или несколько?

1 голос
/ 10 апреля 2020

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

Если бы мы добавили (скажем, концепция домена состоит в том, чтобы назначить) дополнительный объект значения записи в коллекцию, у нас было бы что-то вроде: 

entity.assign_record(...)

, которое подняло бы: 

class RecordAssignedEvent(...)

Прямо вперед.

Теперь представьте ситуацию, когда для инварианта требуется замена всей коллекции. Допустим, метод присвоения теперь заменит все текущие записи в сущности.

ie. 

entity.assign_records(list <records>)

Было бы лучше вызвать одно событие: 

class RecordsAssignedEvent:
    contains details of all records updated

или создайте отдельное событие для назначенной записи, а затем опубликуйте sh коллекцию вместе: 

class RecordAssignedEvent(...)

Мои опасения:

  • Одиночное RecordsAssignedEvent будет содержать много данных ... представьте, 10 записей назначается? 100?
  • События моего домена содержат только примитивные типы. Но если я подниму как отдельное событие, я буду вынужден создать DTO или что-то подобное для включения в коллекцию. Это DTO теперь должно быть доступно любому подписчику мероприятия. Если я поднимаю несколько событий, я легко могу продолжать ограничиваться примитивами.

В приложении DDDSample есть аналогичный сценарий, когда у автомобиля go маршрут состоит из нескольких этапов (в в этом случае сама коллекция является объектом значения, состоящим из объектов значения):

https://github.com/citerus/dddsample-core/blob/master/src/main/java/se/citerus/dddsample/domain/model/cargo/Cargo.java

Есть ли в этих ситуациях какие-либо рекомендации относительно степени детализации событий домена

1 Ответ

3 голосов
/ 11 апреля 2020

Есть ли в этих ситуациях какие-либо рекомендации относительно степени детализации событий в домене?

Если вы ищете руководство по событиям в домене, event-sourcing - это хороший поисковый термин для использования: люди, которые хранят свое доменное состояние в потоке событий, тратят много времени на беспокойство о таких вещах, как гранулярность.

В общем, наличие нескольких событий домена, связанных с одной транзакцией, common . Другими словами, вам не следует стесняться рассматривать несколько доменных событий, когда эта модель лучше подходит для вашего домена, чем отдельное событие.

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

В сложных процессах это часто полезно уметь отслеживать ход событий; C было вызвано B было вызвано A. Работа по выполнению анализа может быть значительно проще, если нам не нужно копаться в B, пытаясь выяснить, какая часть из B была причиной из C.

Ряд одинаковых мотивов для сплоченности в нашем исходном коде также применим к дизайну событий.

Тем не менее, вы обычно хотите причин домена для события нескольких доменов, а не механические причины. Если большой, неудобный для сериализации граф информации действительно является одним изменением атома c на языке вашего домена, то вам действительно следует заняться разработкой подходящей схемы для него, вместо того, чтобы быстро сокращать информацию произвольные границы, чтобы данные соответствовали вашим условным обозначениям схемы.

aka "Это зависит".

...