Количество свойств на команду / событие в источнике событий - PullRequest
0 голосов
/ 18 февраля 2020

Я изучаю cqrs / event sourcing, и недавно я слушал выступление и докладчик сказал, что вам нужно передать как можно меньше параметров, другими словами, чтобы сделать события крошечными, насколько это возможно. Основная причина этого заключается в том, что невозможно изменить события позже, так как это нарушит историю событий, и это легко для правильного проектирования небольших событий. Но что, если, например, в пользовательском интерфейсе вам нужно заполнить, например, форму с 10 полями для создания нового агрегата, и такая же ситуация может быть с обновлением агрегата? Как быть в таком случае? А как быть, если бизнес позже что-то изменит, но у нас есть огромное событие, которое обновляет 10 полей?

Ответы [ 2 ]

1 голос
/ 19 февраля 2020

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

Мотивация для использования Тонкие доменные события должны включать в себя достаточно информации, необходимой для обеспечения перехода состояния.

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

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

Ссылки:

0 голосов
/ 18 февраля 2020

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

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

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

...