Краткая выжимка из ответов на вопрос о распределении данных из чата по микросервисам, показалось важным, так как ситуация распространенная: Вопрос __Есть два микросервиса: документы и авторизация. Документы реализует всю свою бизнес логику, авторизация свою. В документе есть ссылка на пользователя из авторизационного сервиса. Например я делаю грид с документами, где я должен показать не просто id пользователя а его имя фамилию. В каком месте правильнее переводить ID в имя фамилию? На стороне сервиса документов или на стороне UI? __Ответ Если подойти к вопросу с позиции предметно-ориентированного проектирования. Например, у меня есть договор найма. Я меняю фамилию (и паспорт). Это не приводит к автоматическому изменению моих имени и фамилии в договоре найма, это приводит к запуску еще одного (или многих) процесса, кульминацией которого будет изменение договора найма или допник или еще что-то. То есть сервис документов должен узнать, что произошли изменения и выполнить какие-то действия, зафиксировать сам факт изменений, а не просто отобразить при следующем обращении в документе новые имя и фамилию. В такой ситуации стоит рассмотреть вариант хранения имени и фамилии в сервисе документов, так как в описанной ситуации они относятся к модели работы с документами. При необходимости можно обновлять данные об имени и фамилии на основе события-уведомления из сервиса авторизации. С другой стороны, если это только чтение и никакой логики касательно имени и фамилии нет в предметной области (которая шире кода), то BFF здесь выглядит наиболее рациональным. Да в этом случае это дополнительные накладные расходы, – дополнительный сервис, кодинг, деплой и проч, но зато чистый сервис документов, который ничего не знает о сервисе авторизации и его API + масштабирование выглядит более простым в случае необходимости. И, конечно, всегда есть простой вариант в виду вызова API сервиса авторизации, но это связывает сервисы документов и авторизации напрямую, что создает между ними достаточно сильную зависимость и, возможно, порождает потребность в координации. Ссылка на оригинальное обсуждение: https://t.me/microservices_ru/26794
Краткая выжимка из ответов на вопрос о распределении данных из чата по…
Из этого канала
- #498Нашел в архиве требования безопасности, уж не помню к какому точно проекту…
Нашел в архиве требования безопасности, уж не помню к какому точно проекту формулировал, еще в 2012-м году, может кому-то будет полезно.
- #499Почти совсем оффтопик. Очень давно посмотрел этот ролик и все никак не мог…
Почти совсем оффтопик. Очень давно посмотрел этот ролик и все никак не мог потом найти, – название не запомнил.
- #500Почитать под вечерний кофе…
Почитать под вечерний кофе https://www.infoq.com/news/2023/10/uber-up-cloud-microservices/
- #496"🧩 Виды прототипов в связке с архитектурой Макет/демо Цель – получить…
"🧩 Виды прототипов в связке с архитектурой Макет/демо Цель – получить представление о том, как продукт должен выглядеть.
- #495♻️ Виды потерь, через призму которых можно посмотреть и на процессы,…
♻️ Виды потерь, через призму которых можно посмотреть и на процессы, относящиеся к работе с архитектурой Неэффективная верификация Неэффективное тестирование,…