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

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

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

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

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

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

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

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



tgoop.com/microservices_arch/497
Create:
Last Update:

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

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

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

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

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

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

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

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

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


Share with your friend now:
tgoop.com/microservices_arch/497

View MORE
Open in Telegram


Telegram News

Date: |

Telegram Android app: Open the chats list, click the menu icon and select “New Channel.” Informative Among the requests, the Brazilian electoral Court wanted to know if they could obtain data on the origins of malicious content posted on the platform. According to the TSE, this would enable the authorities to track false content and identify the user responsible for publishing it in the first place. Select “New Channel” Don’t publish new content at nighttime. Since not all users disable notifications for the night, you risk inadvertently disturbing them.
from us


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