Модель общего домена между различными микросервисами

Представьте себе сценарий двух разных микросервисов. Один для обработки аутентификации внутри службы, другой для управления пользователями. У них обоих есть понятие пользователя, и они будут говорить о пользователях посредством звонков друг другу.

Куда бы принадлежала модель Домена «Пользователь»? Будет ли у них другое представление о том, что пользователь находится на уровне базы данных? Как насчет того, когда у нас есть UserDTO, который будет использоваться в вызовах API, у них обоих будет один для их соответствующих API?

Что является общепринятым решением для такого архитектурного вопроса?

В архитектуре микросервисов каждый из них абсолютно независим от других и должен скрывать детали внутренней реализации.

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

Если они слишком связаны, возможно, они действительно такие, как @soru говорит.

Смежные вопросы:

• Почему так плохо читать данные из базы данных, «принадлежащей» другому микросервису?
• Как вы работаете с общими понятиями в микросервисной архитектуре?

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

Конечно, пример не имеет большого смысла как две службы; трудно представить спецификацию «Управление пользователями», настолько сложную, что вся команда будет настолько занята, что у них не будет времени для аутентификации.

Если бы по какой-то причине они были, то они общались бы, используя в основном произвольные строки, как в OAuth 2.0 .

Вы можете думать о них как о двух отдельных ограниченных контекстах (на языке доменного дизайна). Они не должны делиться какими-либо данными между ними, кроме идентификатора, используемого для сопоставления «Пользователь» контекста аутентификации с «Пользователь» другого контекста. Каждый из них может иметь собственное представление о том, что такое «пользователь», и свою собственную модель домена, которая представляет собой только ту информацию, которая необходима для выполнения их бизнес-обязанностей.

Помните, что модель предметной области не пытается моделировать «вещь» реального мира, но что это за вещь в конкретном контексте (например, управление идентификацией / авторизацией, управление персоналом и т. Д.).

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

Я также согласен с тем, что сказал @soru. Если одному сервису нужны данные другого сервиса, его границы неверны.

Хорошее решение - то, что придумал @pnschofield - рассматривая ваши сервисы как ограниченный контекст

Говоря о предмете, коротко говоря: модели с общим доменом убивают автономность службы, превращая вашу микросервисную систему в распределенный монолит. Что, видимо, даже хуже, чем монолит.

Таким образом, все еще остается нерешенным общий вопрос - как определить границы обслуживания или контекста, чтобы они процветали с высокой связностью и безупречным качеством связи.

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

Моя типичная последовательность шагов, которые я предпринимаю при определении границ сервиса, следующая:

1. Определите бизнес-возможности более высокого уровня. Обычно они похожи между организациями из одного домена. Вы можете почувствовать, как выглядит проверка цепочки создания стоимости Портера .
2. В рамках каждой возможности углубиться и определить под-возможности.
3. Обратите внимание на связь между возможностями. Посмотрите, что делает организация. Обычно общение сосредоточено в пределах возможностей, оповещая остальных о результате своей работы. Таким образом, при реализации технической архитектуры ваш сервис должен также общаться через события. Это имеет несколько положительных последствий. При таком подходе ваши услуги автономны и согласованы. Им не нужно синхронное общение и распределенные транзакции.

Вероятно, пример этой техники будет интересен для вас. Не стесняйтесь, дайте мне знать, что вы думаете, так как я нашел этот подход действительно выгодным. Конечно, это может сработать и для вас.

Микросервис - это не «ничего не делиться», а «делиться как можно меньше». В большинстве случаев «Пользователь» является действительно общей сущностью (просто потому, что Пользователь идентифицируется некоторым общим идентификатором - userId / email / phone). Такой вид сущностей разделен по определению. Пользовательская модель выходит за рамки одного микросервиса. Таким образом, у вас должна быть глобальная схема, в которой должен быть размещен пользователь (только его наиболее распространенные поля). В строгом случае это только идентификатор.