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

61

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

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

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

Kristof
источник

Ответы:

36

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

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

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

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

gabrielgiussi
источник
21
Я не могу полностью согласиться, если они полностью независимы, то у вас есть 2 монолита. Идея состоит в том, чтобы иметь умные конечные точки и тупые трубы. В корпоративном контексте вы в конечном итоге (в настоящее время мой кошмар) попадаете в стену, потому что существует неявная модель общего домена (неявная, потому что мы ее не предвидели), и каждая служба заново изобретает% от колеса. И экосистема микросервисов растет с акцентом на 100% функциональности и коллективной собственности, что портит модель предметной области. У нас есть команды, создающие новые сервисы, потребляющие другие, дублирующие большие усилия. Все еще не решено.
juanmf
5
Мы также оставили в стороне очень важное Нефункциональное требование к архитектуре - производительность. Эти сервисы, требующие вывода других сервисов, обеспечивают многоуровневый подход к коммуникации для каждого клиентского RQ. Добавление задержки, которая не может быть устранена, если не будет произведен значительный рефакторинг и, возможно, слияние микро-сервисов.
juanmf
3
Кроме того, отсутствие общего понимания модели предметной области вынуждает команды применять ненужные преобразования «unmarshalling + object-object» для адаптации откликов микро-сервисов к модели, принятой вызывающим микро-сервисом. Я знаю, что соединение всех сервисов с общей библиотекой модели домена может привести к другим операционным проблемам, но я не нахожу ни один из вариантов, удовлетворяющих.
juanmf
3
@juanmf Было бы очень полезно, если бы вы могли опубликовать вопрос о своих проблемах. Мне также интересно услышать мнения по этому вопросу ...
Милош Мрдович
1
Я попытаюсь сесть и написать что-нибудь, что имеет смысл
18:00
13

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

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

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

Сору
источник
4

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

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

pnschofield
источник
2

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

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

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

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

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

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

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

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

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

Западло
источник
1

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

Евгений Остапенко
источник