tgoop.com/emacsway_log/1464
Last Update:
Возвращаясь к вопросу о Командах/Событиях.
Команда является входящим портом доменной модели. Событие является результатом исполнения команды, т.е. исходящим портом. Говоря метафорически, Команда - это входные аргументы функции. Событие - это возвращаемое значение функцией.
Возникает вопрос - а где размещается логика, отвечающая за то, чтобы в ответ на Событие была инициирована необходимая Команда?
Ответ зависит от типа Relationship между Bounded Context (BC).
Допустим, заказ укомплектован и его нужно передать в доставку, т.е. доставить. Доставить груз/посылку. Обратите внимание на использование другого термина, которым утрачена избыточная определенность об оригинале, т.е. найдена новая абстракция, а значит, найдена новая модель с другим ubiquitous language.
Событие происходит в одной модели, а команда исполняется в другой модели. Между моделями происходит трансляция языка. Допустим, что каждый BC выражен отдельным сервисом. В каком сервисе разместить эту трансляцию?
Предположим, трансляция осуществляется в сервисе логистики, который подписан на Событие склада. Тогда это Anti-corruption Layer.
Или же она осуществляется в сервисе склада, т.е. в паблишере события. И в шину отправляется уже Команда, а не Событие. Тогда это Open Host Service, обычно с Published Language.
Реализуется слой трансляции, как правило, в виде адаптеров хексагональной архитектуры.
Выбирая между отправкой в шину Команды или События, мы можем управлять направлением осведомленности. Когда отправляем Событие, то подписчик осведомлен о доменной модели издателя. Когда Команду, то издатель осведомлен о доменной модели исполнителя.
Обычно domain specific сервис осведомлен о generic сервисах. Но тут есть нюанс, который раскрывается в этой статье Nick Tune.
BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Share with your friend now:
tgoop.com/emacsway_log/1464