микросервисы и ограниченные контексты

Question

На вопрос, у меня есть 2 микросервиса.

• Управление идентификацией
• Учет

Я знаю, что каждый microservice не должно быть тесно связаны, и она должна иметь свою собственную базу данных.

Предположим, что учетная запись имеет счета-фактуры, и каждый счет-фактура имеет выдающего агента. Агент от бухгалтерского учета также существует как пользователь в микросервисе Identity.

Если я правильно понял, данные управления идентификацией (пользователями) должны быть скопированы в учет (агенты) и должны копировать только те данные, которые необходимы для этого ограниченного контекста (имя и фамилия), поэтому счет может иметь правильный issuingAgentId.

Правильно ли это, чтобы данные согласовывались и делились между контекстами? Каждый раз, когда пользователь создается в микросервисе идентификации, событие «UserCreated» будет опубликовано, а учет или любая другая услуга, заинтересованная в этом событии, должна слушать и обрабатывать его, добавляя соответствующий агент? То же самое касается обновления информации о пользователе.

Answer 1

Это один из способов справиться с этим да и обычно предпочтительный метод. Вы храните кеш локально в своей службе, который хранит копии данных из другой службы. В управляемой событиями системе это предполагает прослушивание интересующих событий и их использование для обновления локального кеша. Кэш может быть в памяти или сохранен. Примером для вашего случая использования было бы при создании счета-фактуры, контекст учета будет выглядеть в локальном кэше для пользователя/агента перед созданием счета-фактуры.

Другие варианты:

общая база данных

Я знаю, что неодобрительно (по уважительной причине), но вы всегда можете разделить схему базы данных. Например, контекст Identity может записывать в пользовательскую таблицу, и контекст учета может считываться из него, когда ему нужно, чтобы AgentId вставлял счет-фактуру. Компромисс заключается в том, что вы соединяетесь на уровне базы данных и вводите единую точку отказа.

RPC

Вы можете сделать вызов RPC на другую службу, когда вам нужна информация. В вашем примере контекст Accounting вызовет контекст управления идентификацией для информации AgentId/User перед тем, как выставить счет-фактуру. Компромисс с этим подходом снова связан с другой услугой. Что вы делаете, когда оно недоступно? Вы не можете выставлять счет-фактуру.

Отчетный домен

Другим вариантом является совершенно отдельный сервис, который прослушивает данные из других служб и поддерживает просмотр моделей UIs. Это позволит другим вашим службам не знать о проблемах других служб. При использовании управляемой событиями системы вы будете слушать события из других служб, которые позволят вам создать модель представления для пользовательского интерфейса. Обычно это хороший вариант, если все, что вы делаете, это просмотр данных