В DDD: команды, которые генерируют события, которые никто не потребляет

Question

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

Мои вопросы:

1. должна ли команда произвести событие?

2. Если так, то имеет ли значение, что никто не слушает?

Answer 1

должна ли команда произвести событие?

Абсолютно нет.

Если бы вы использовали event sourcing в качестве своей стратегии постоянства, то все ваши изменения состояния были бы "событиями". Но нет особой причины, по которой вы должны выставить событие в другом месте.

Закон Хайрама - это одна из причин, по которой вы предпочитаете не транслировать событие

При достаточном количестве пользователей API, не имеет значения, что вы обещаете в договоре: все наблюдаемые поведения вашей системы будет зависеть от кого-то.

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

имеет значение, что никто не слушает?

В идеальном мире, а не на самом деле - на практике затраты могут быть частью решения.

Answer 2

должна ли команда произвести событие?

Нет, это не является обязательным требованием, команда может просто изменить состояние объекта, не отправляя событие.Как сказано в других ответах, вы должны требовать, чтобы каждое изменение состояния создавало событие домена , если вы используете Event Sourcing .

Если это так, имеет ли значение, чтоникто не слушает?

Да и нет.

• Да, потому что нет хорошей или плохой модели, есть только полезная модель, если никто не слушает, то ваше моделирование недействительно полезен для всех.
• Нет, поскольку доменные события называются инвариантами , они отражают бизнес-события и изменяются только при изменении бизнес-требований и поэтому являются частью вашего API (см. концепциюопубликованного языка).

Answer 3

1. Для команды не обязательно создавать событие, хотя это и предпочтительнее.Одним из наиболее значительных преимуществ событий является возможность генерировать состояние системы как на определенную дату / время с нуля.Если вы были религиозно всплывающими событиями для всех изменений в системе, вы сможете применять события последовательно и приводить систему в состояние, соответствующее вашему требованию.

2. ИМХО, этоне имеет значения, что никто не слушает в этот момент времени.Я предполагаю, что вы сохраняете свое событие в приемнике / журнале событий как часть вашего приложения.Это дает два преимущества:

   a.Если бы вам предстояло обнаружить будущие требования, которые могли бы извлечь пользу из журнала событий, вы уже на шаг впереди.

   b.Даже если никто и никогда не использует событие, как упоминалось в первом ответе, возможность генерировать состояние системы по состоянию на определенную дату / время - это крутая возможность иметь.

Модель постоянных событий и получения состояния системы берет свое начало в Event Sourcing.Вы бы хотели глубже взглянуть на него, чтобы увидеть его преимущества.