Проверка полезных данных команд в архитектуре микросервисов, полученных из событий

Question

Я не совсем понимаю, как реализовать проверку данных в архитектуре микросервисов, основанных на событиях.

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

Затем из-за тонны материалов в inte rnet и книг в DDD (Domain Driven Design) я создаю архитектуру микросервисов следующего источника. Компоненты
1. API Getaway для приема вызовов REST от клиентов и преобразования их в команды.
2 Обработчик команд в качестве службы. Получите команды от API. Сделайте валидацию. Сохраните события в хранилище событий и опубликуйте sh события на шине событий.
3. Хранилище событий - это хранилище для всех событий в системе. Позволяет нам воссоздать состояние приложения. Главное состояние истины.
4. Микро-сервисы - это небольшие сервисы, отвечающие за обработку событий, связанных с его доменом. Сделайте некоторые прогнозы для локальных частных баз данных. Сделайте также некоторые события.

И у меня есть вопросы, на которые я не смог бы ответить ни себе, ни целым rnet.
1. Что такое на самом деле совокупности. Это объекты класса / записи в базах данных, как я думаю или что?
2. Кто занимается агрегатами. Я нашел пример того, что в некоторых случаях их использует обработчик команд. Но в этом случае, если агрегаты хранятся в частных базах данных микро-сервисов, тогда у нас будет очень высокая связь между обработчиком команд и каждым из микро-сервисов, и это неправильно из-за концепции микро-сервисов.

Подводя итог.
Я запутался в том, как реализовать агрегирование в архитектуре микросервиса источника событий.
Например, давайте сосредоточимся на реализации регистрации пользователя в архитектуре микросервиса источника события.

У нас есть пользовательский домен, поэтому архитектура будет следующей.
Отпуск API
Обработчик команд
Микросервис аутентификации
Микросервис пользователя

Пожалуйста, объясните мне реализацию проверки команды в соответствии с примером выше.

Answer 1

Обработчик команд как сервис

Я думаю, что это основной источник вашей путаницы.

Обычно обработчик команд не является сервисом сам по себе. Это образец. Обычно он работает в том же процессе, что и сам «микросервис».

IE: обработчик команд считывает сообщение из хранилища и сам вызывает логос микросервиса c, который вычисляет, как интегрировать информация в этом сообщении в своем собственном представлении о мире.

Что на самом деле является агрегатами

«Агрегат» - это шаблон управления жизненным циклом; агрегат - это граф одного или нескольких доменных объектов, которые вместе установят sh и сохранят некоторый интересный инвариант. Это один из трех шаблонов, подробно описанных в книге «Управляемый доменом», написанной Эри c Эвансом.

Обработчик команд плюс ваш агрегат - это , в некотором смысле ваш микросервис. Микросервис обычно обрабатывает сообщения для нескольких экземпляров одного агрегата - он подписывается на все входные сообщения для такого рода агрегатов. Часть «обработчик» просто читает следующее сообщение, загружает соответствующий экземпляр агрегата, затем выполняет логины домена c (определенные в агрегатных объектах) и сохраняет результаты.