Представьте себе сценарий двух разных микросервисов. Один для обработки аутентификации внутри службы, другой для управления пользователями. У них обоих есть понятие пользователя, и они будут говорить о пользователях посредством звонков друг другу.
Куда бы принадлежала модель Домена «Пользователь»? Будет ли у них другое представление о том, что пользователь находится на уровне базы данных? Как насчет того, когда у нас есть UserDTO, который будет использоваться в вызовах API, у них обоих будет один для их соответствующих API?
Что является общепринятым решением для такого архитектурного вопроса?
architecture
microservices
Kristof
источник
источник
Если две службы в достаточной степени переплетены между собой, так что было бы сложно реализовать их без совместного использования DTO и других объектов модели, это сильный знак, что у вас не должно быть двух служб.
Конечно, пример не имеет большого смысла как две службы; трудно представить спецификацию «Управление пользователями», настолько сложную, что вся команда будет настолько занята, что у них не будет времени для аутентификации.
Если бы по какой-то причине они были, то они общались бы, используя в основном произвольные строки, как в OAuth 2.0 .
источник
Вы можете думать о них как о двух отдельных ограниченных контекстах (на языке доменного дизайна). Они не должны делиться какими-либо данными между ними, кроме идентификатора, используемого для сопоставления «Пользователь» контекста аутентификации с «Пользователь» другого контекста. Каждый из них может иметь собственное представление о том, что такое «пользователь», и свою собственную модель домена, которая представляет собой только ту информацию, которая необходима для выполнения их бизнес-обязанностей.
Помните, что модель предметной области не пытается моделировать «вещь» реального мира, но что это за вещь в конкретном контексте (например, управление идентификацией / авторизацией, управление персоналом и т. Д.).
источник
Я также согласен с тем, что сказал @soru. Если одному сервису нужны данные другого сервиса, его границы неверны.
Хорошее решение - то, что придумал @pnschofield - рассматривая ваши сервисы как ограниченный контекст
Говоря о предмете, коротко говоря: модели с общим доменом убивают автономность службы, превращая вашу микросервисную систему в распределенный монолит. Что, видимо, даже хуже, чем монолит.
Таким образом, все еще остается нерешенным общий вопрос - как определить границы обслуживания или контекста, чтобы они процветали с высокой связностью и безупречным качеством связи.
Я придумал решение, позволяющее рассматривать мои контексты как возможности для бизнеса. Это бизнес-ответственность более высокого уровня, бизнес-функциональность, способствующая достижению общей бизнес-цели. Вы можете думать о них как о шагах, которые должна пройти ваша организация, чтобы получить бизнес-ценность.
Моя типичная последовательность шагов, которые я предпринимаю при определении границ сервиса, следующая:
Вероятно, пример этой техники будет интересен для вас. Не стесняйтесь, дайте мне знать, что вы думаете, так как я нашел этот подход действительно выгодным. Конечно, это может сработать и для вас.
источник
Микросервис - это не «ничего не делиться», а «делиться как можно меньше». В большинстве случаев «Пользователь» является действительно общей сущностью (просто потому, что Пользователь идентифицируется некоторым общим идентификатором - userId / email / phone). Такой вид сущностей разделен по определению. Пользовательская модель выходит за рамки одного микросервиса. Таким образом, у вас должна быть глобальная схема, в которой должен быть размещен пользователь (только его наиболее распространенные поля). В строгом случае это только идентификатор.
источник