Микросервисы / распределенные системы

Краткая выжимка из ответов на вопрос о распределении данных из чата по микросервисам, показалось важным, так как ситуация распространенная:

Вопрос
Есть два микросервиса: документы и авторизация. Документы реализует всю свою бизнес логику, авторизация свою. В документе есть ссылка на пользователя из авторизационного сервиса. Например я делаю грид с документами, где я должен показать не просто id пользователя а его имя фамилию. В каком месте правильнее переводить ID в имя фамилию? На стороне сервиса документов или на стороне UI?

Ответ
Если подойти к вопросу с позиции предметно-ориентированного проектирования.

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

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

С другой стороны, если это только чтение и никакой логики касательно имени и фамилии нет в предметной области (которая шире кода), то BFF здесь выглядит наиболее рациональным. Да в этом случае это дополнительные накладные расходы, – дополнительный сервис, кодинг, деплой и проч, но зато чистый сервис документов, который ничего не знает о сервисе авторизации и его API + масштабирование выглядит более простым в случае необходимости.

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

Ссылка на оригинальное обсуждение: https://www.tgoop.com/microservices_ru/26794

❤2👍2🔥2

www.tgoop.com/microservices_arch/497

2.31K viewsSergey Baranov, Nov 2, 2023 at 13:06

Краткая выжимка из ответов на вопрос о распределении данных из чата по микросервисам, показалось важным, так как ситуация распространенная:

Вопрос
Есть два микросервиса: документы и авторизация. Документы реализует всю свою бизнес логику, авторизация свою. В документе есть ссылка на пользователя из авторизационного сервиса. Например я делаю грид с документами, где я должен показать не просто id пользователя а его имя фамилию. В каком месте правильнее переводить ID в имя фамилию? На стороне сервиса документов или на стороне UI?

Ответ
Если подойти к вопросу с позиции предметно-ориентированного проектирования.

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

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

С другой стороны, если это только чтение и никакой логики касательно имени и фамилии нет в предметной области (которая шире кода), то BFF здесь выглядит наиболее рациональным. Да в этом случае это дополнительные накладные расходы, – дополнительный сервис, кодинг, деплой и проч, но зато чистый сервис документов, который ничего не знает о сервисе авторизации и его API + масштабирование выглядит более простым в случае необходимости.

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

Ссылка на оригинальное обсуждение: https://www.tgoop.com/microservices_ru/26794

BY Микросервисы / распределенные системы