Итак, проблема в том, должен ли микросервис air-miles принимать решения на основе своей собственной модели представления, которая обновляется на основе событий, поступающих с текущего счета, и аналогичным образом, на основе выбора вознаграждения, которое он должен датьЗаказчик?
Да.Фактически, вы должны пересмотреть свою архитектуру и даже создать больше микросервисов.Я имею в виду, что, будучи архитектурой, управляемой событиями (также основанной на событиях), ваши микросервисы имеют две обязанности: они должны поддерживать две разные модели: модель записи и модель чтения.
Таким образом, для каждого Агрегата должен быть микросервис, который поддерживает только модель записи, то есть обрабатывает только Команды, без построения также модели чтения.
Затем для каждого чтения / запросаВ случае использования у вас должен быть микросервис, который создает модель чтения perfect .Это необходимо, если вам нужно поддерживать агрегированный микросервис в чистоте (как следует), потому что в общем случае для моделей чтения требуются данные из нескольких агрегированных типов / ограниченных контекстов.Считанные модели могут пересекать ограниченные контекстные границы, агрегаты - нет.Итак, вы видите, у вас действительно нет выбора, если вам нужно полностью соблюдать DDD.
Некоторые говорят, что доменные события должны быть скрытыми, только локальными по отношению к собственному микросервису.Я не согласен.В управляемой событиями архитектуре доменные события являются гражданами первого класса, им разрешено достигать других микросервисов.Это дает другим микросервисам возможность построить свою собственную интерпретацию состояния системы.В противном случае испускающая микросервис будет иметь невозможную дополнительную ответственность / задачу построения состояния, которое должно соответствовать всем возможным потребностям, которые когда-либо понадобятся всем микросервисам (!);то есть, может быть, микросервисам захочется найти удаленных удаленных объектов title, как он может это сделать, если испускающий микросервис хранит только список не удаленных, но все же объектов?Вы можете сказать: но тогда он сохранит все сущности, удаленные или нет.Но, возможно, кому-то нужна дата, когда объект был удален;Вы можете сказать: но тогда я сохраняю и deletedDate.Вы видите, что вы делаете?Вы нарушаете принцип Open / Closed.Каждый раз, когда вы создаете микросервис, вам нужно модифицировать испускающий микросервис.
Существует также устойчивость микросервисов.В Искусство масштабируемости авторы говорят о плавательных дорожках.Они представляют собой стратегию разделения компонентов системы на полосы отказов.Отказ в полосе не распространяется на другие полосы.Наши микроуслуги - это дорожки.Компонентам на линии не разрешен доступ к любому компоненту с другой линии.Один микросервис не должен сбивать других.Это не вопрос скорости / оптимизации, это вопрос устойчивости.События в домене - это идеальный способ синхронизации двух удаленных систем.Они также подчеркивают тот факт, что данные в конечном итоге согласованы;события развиваются с ограниченной скоростью (от наносекунд до четных дней).Если система спроектирована с учетом этого, никакая другая микросервисная служба не сможет ее отключить.
Да, будет некоторое дублирование кода.И да, хотя я сказал, что у вас нет выбора, у вас есть.Чтобы уменьшить дублирование кода за счет более низкой устойчивости, у вас могут быть некоторые модели чтения Canonical, которые строят нормальное плоское состояние, и другие микросервисы могут запросить это.В большинстве случаев это опасно, поскольку нарушает концепцию плавательных дорожек.Если микросервисы Canonical выйдут из строя, отключите все зависимые микросервисы.Микросервисы Canonical лучше всего работают для CRUD-подобного ограниченного контекста.
Однако существуют допустимые случаи, когда у вас могут быть некоторые внутренние события, которые вы не хотите раскрывать.Другими словами, вы не обязаны публиковать все события домена.