Модель спільного домену між різними мікросервісами

Уявіть сценарій двох різних мікросервісів. Один для обробки автентифікації в рамках сервісу, інший - для управління користувачами. Вони обидва мають поняття «Користувач» і будуть говорити про користувачів через дзвінки один одному.

Де б належала модель домену "Користувача"? Чи мали б вони обидва різного представлення того, що Користувач знаходиться на рівні бази даних? Що робити, коли у нас є UserDTO, який буде використовуватися у викликах API, чи буде вони обоє для відповідних API?

Яке загальноприйняте рішення такого роду архітектурного питання?

У архітектурі мікросервісів кожна з них абсолютно не залежить від інших, і вона повинна приховувати деталі внутрішньої реалізації.

Якщо ви поділитесь моделлю, ви з'єднуєте мікросервіси і втрачаєте одне з найбільших переваг, за якого кожна команда може розвивати свою мікросервіс без обмежень та потребу знати, як розвиваються інші мікросервіси. Пам'ятайте, що ви можете навіть використовувати різні мови в кожній, це буде складно, якщо ви почнете пару мікросервісів.

Якщо вони занадто споріднені, можливо, вони справді такі, як говорить @soru.

Пов’язані запитання:

• Чому так погано читати дані з бази даних, "власником" якої є інша мікросервіс
• Як ви обробляєте спільні концепції в архітектурі мікросервісу?

Якщо два сервіси достатньо переплетені між собою, було б болісно реалізовувати їх без спільного використання DTO та інших об'єктів моделі, це сильний знак, що у вас не повинно бути двох служб.

Безумовно, приклад має мало сенсу як дві послуги; важко уявити специфікацію для "Керування користувачами" настільки складною, що вона би тримала цілу команду настільки зайнятою, що вони не встигають пройти автентифікацію.

Якби вони з якихось причин були, то вони спілкувалися б, використовуючи в основному довільні рядки, як в OAuth 2.0 .

Ви можете вважати їх двома окремими обмеженими контекстами (на мові, орієнтованій на домен). Вони не повинні ділитися між собою будь-якими даними, окрім ідентифікатора, який використовується для співвіднесення "Користувача" контексту аутентифікації з "Користувачем" іншого контексту. Кожен може мати власне уявлення про те, що таке "Користувач", і свою власну доменну модель, яка є лише інформацією, необхідною для виконання бізнес-відповідальності.

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

Вони обидва мають поняття «Користувач» і будуть говорити про користувачів через дзвінки один одному.

Я також згоден з тим, що сказав @soru. Якщо одній службі потрібні дані іншої служби, їх межі неправильні.

Гарне рішення - це те, що придумав @pnschofield - трактувати ваші послуги як обмежений контекст.

Якщо говорити про цю тему, коротко: моделі спільних доменів вбивають автономію сервісу, перетворюючи вашу мікросервісну систему в розподілений моноліт. Що, мабуть, навіть гірше, ніж моноліт.

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

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

Моя типова послідовність кроків, які я виконую під час визначення меж обслуговування, така:

1. Визначте бізнес-можливості вищого рівня. Зазвичай вони схожі серед організацій з одного домену. Ви можете відчути, як виглядає перевірка моделі ланцюга вартості Портера .
2. У межах кожної з можливостей поглибимось глибше та визначте під-можливості.
3. Зверніть увагу на зв’язок між можливостями. Подивіться, що робить організація. Зазвичай спілкування зосереджено в межах можливостей, сповіщаючи решту про результат своєї роботи. Тож, впроваджуючи технічну архітектуру, ваша служба повинна також спілкуватися через події. Це має численні позитивні наслідки. При такому підході ваші послуги стають автономними та згуртованими. Вони не потребують синхронного зв'язку та розподілених транзакцій.

Можливо, приклад цієї методики зацікавив би вас. Не соромтеся повідомити мені, що ви думаєте, оскільки я вважаю такий підхід справді вигідним. Впевнені, що це може спрацювати і для вас.

Мікросервіс не в тому, щоб "ділитися нічого", а "поділитися якомога менше". У більшості випадків "Користувач" - це дійсно звичайна суть (лише тому, що Користувача ідентифікує якийсь спільний ідентифікатор - userId / email / phone). Такі види сутностей поділяються за визначенням. Модель користувача виходить за межі однієї мікросервіси. Отже, у вас повинна бути якась глобальна схема, де слід розмістити Користувача (лише його найпоширеніші поля). У суворій справі є лише ідентифікатор.