#domain-driven-design #event-sourcing
#дизайн, управляемый доменом #источник событий
Вопрос:
Я практикую штурм событий, используя стикеры и материалы.
Но не хватает одной вещи: проверки команды (правила, которые должны быть выполнены для принятия команды / успешного выполнения).
Как сделать это видимым на доске? (не только в виде комментариев, разбросанных тут и там). При штурме событий упоминаются только «события» (желтый), «команда» (синий), «совокупность» (бледно-желтый) и т.д. Я не рассматриваю «проверку команды» как гражданина первого класса.
Есть мысли?
Комментарии:
1. Я бы сказал, что правила, которые должны выполняться для принятия / успешного выполнения команды, являются частью ваших «агрегатов». Или, если быть более точным, это часть вашей модели записи, которая находится между командой и событием.
2. Выберите новый цвет стикера (какой хотите — важно только, чтобы вы и ваша команда понимали это) и разместите его там, где это имеет смысл на доске. Это зависит от типов проверки, которые вы документируете, но, скорее всего, это будет где-то между командой и агрегатом.
Ответ №1:
Я бы рассматривал проверку команд как политику при штурме событий. Это бизнес-правила, которые должны быть выполнены, чтобы команда была принята.
Они будут отображаться в розовой заметке «политика» — https://eventnotes.io/pdf/cheatsheet-big-picture-exploration.pdf
Я рассматриваю политики как:
- Контролируйте, как выполняется действие
- Бизнес-правила
- Решения
- Когда происходит событие, вы применяете политику и решаете, каким будет следующее действие
- Реактивная логика
- Внешнее решение
- Основанный на времени
- На основе триггера
- Реагирует на события
- Запускает команды
- Часто на границе домена
Ответ №2:
У меня была такая же проблема, и я справился с ней следующим образом…. Сначала поймите, что существуют разные типы проверки. Какой тип проверки вы хотите выполнить?
Вы хотите проверить модель, чтобы убедиться, что адрес заказа правильно отформатирован? Это распространялось бы только на проверку «схемы» и могло бы выполняться синхронно как часть вашей команды, и было бы тем, что я бы назвал проверкой команды. Я бы сделал где-нибудь пометку с языком, поскольку это будет использовано для построения контракта.
Вы хотите подтвердить, что «если запасов недостаточно для выполнения заказа, заказ должен завершиться неудачей»? Это не ответственность команд за проверку бизнес-логики, это совокупность; и я бы назвал это проверкой домена. Я использую негативные события, чтобы указать, что в совокупности произошла какая-то форма проверки.
Я надеюсь, что это помогает