Можно ли иметь «технические» события при моделировании модели предметной области?

Question

В настоящее время я моделирую основанную на источнике событий логику домена для одного из моих проектов.

Она основана на CQRS с денормализованной стороной чтения sql и потоками событий на стороне записи.

У меня есть требование, чтобы одна из сущностей домена имела какое-то свойство status (это в основном перечисление).status может быть изменено двумя способами: либо пользователем системы напрямую, либо вследствие других изменений в системе.С точки зрения домена, только изменение пользователя является истинным изменением и, таким образом, заслуживает для его собственного события, другие переходы статуса могут быть рассчитаны из текущего состояния (другие свойства).

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

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

Answer 1

статус может быть изменен двумя способами: либо пользователем системы напрямую, либо в результате других изменений в системе.

Затем вы должны зафиксировать это в своем домене.События.С чисто логической точки зрения тот факт, что status изменился, не зависит от причины: если пользователь изменяет его, то он изменяется;если система изменяет это, то оно изменяется (используемый будет видеть это как измененное, правильно?).Итак, с точки зрения статуса, он меняется в любой ситуации.

Для вашего домена важно, почему тогда status изменилось, поэтому вы должны зафиксировать это в самом событии.Например, событие может выглядеть так: StatusChanged(enum newValue, bool changedByTheUser).

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

if(!event.changedByTheUser and event.date < '2019-01-02'){ /* ignore it */}

Answer 2

Краткий ответ: полиция источников событий не собирается преследовать вас.

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

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

Пример: «Раньше покупки на сумму более 100 долларов США требовали одобрения менеджера, но с этого момента этот порог составляет 50 долларов США».Итак, у нас есть запрос на покупку на 75 грн.Нужно ли было одобрение?Ну, это зависит от того, какой набор правил действовал, когда цена была сделана.Куда вы собираетесь это записывать?

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