получается у тебя фронт 1->1 бэкэнд 1->N бэкэнд-> база

это нормальная схема, тут больше проблема с неймингом

то что один из бэкэндов становится бд

нахера в этой цепочке 2 бэкенда и прослойка эта?

что у тебя "2 бэкэнда"? две хрени общающиеся по http ?

и все работает по http со всем оверхедом

это норм?

ну если ты хочешь так делать - то как хочешь) я такого не предлагал)

ну хорошо какие именно слова я твои не так понял?

про агрегатор?

я нигде не говорил ни о двух бэкэндах ни о чем-то таком еще

так то что ты бэкэнд назвал агрегатор сути это не поменяло

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

опять абстрактные кони

тут гибкость в том что мы можем менять то что нам надо отдать без каких-либо изменений в ниже лежащих модулях

опять абстрактные кони

блин один объект дергает методы других объектов, че тут абстрактное.

конкретную стори с новостями, комментариями и польльзователями привели

конкретную стори с новостями, комментариями и польльзователями привели

ну и сверху модуль API который просто дергает методы объектов из этих трех модулей.

и собирает из этого JSON

если ты по микросервисам упарываешься - будет отдельный сервер api gateway

если нет - можно без подобных выкрутасов

профит - гибкость

минус - производительность не на максимуме

гибкость?

soa

повторюсь - это если ты микросервисами упарываешься

я не упарываюсь ими

если тебе не нужно распределенное приложение и ты делаешь монолит - у тебя вся коммуникация между модулями будет в рамках одного процесса

я говорю что здесь оно нафиг не нужно в 99% случаев

что "оно"?

микросервисы

короч, повторю еще раз для тебя

или soa

так ты сам начал про soa/микросервисы своими двумя бэкэндами)

я начал?

да, как всегда)

я предлагаю просто объект который будет представлять агрегацию данных для одного скрина. Ориентированнйы по требования клиента

объект, не отдельный сервер какой-то, просто еще один объект сверху этих трех модулей

4-ый модуль с 3-мя зависимостями

так если тебе для этого скрина потом понадобятся еще какие-то данные - надо поправить в одном месте

и все рады и довольны, у нас и со связанностью все хорошо, и клиент получает то что ему надо

минусы - application level joins таки медленнее джойнов в базе.

я предлагаю просто объект который будет представлять агрегацию данных для одного скрина. Ориентированнйы по требования клиента

вот

альтернатива - делать отдельную read model со связанностью на уровне базы

но тогда выйдет неявно

но суть в том что от зависимостей между модулями не избавиться

потому что

есть модуль комментариев и модуль юзера

но суть в том что от зависимостей между модулями не избавиться

модули комментов, новостей и юзеров ничего друг о друге не знают

допустим мы делаем их независимыми

разными командами и людьми

которые не могут общаться между собой

которые не могут общаться между собой

могут, просто мы хотим свести это общение к минимуму

тогда команда что делает модуль комментариев скажет, что это за хуйня в таблице коментариев с user_id

удаляем нахуй

и удалит и будет права

не будет

потому что оно нахуй не нужно

но тут юзеры прикурят

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

просто у них автор будет представлен айдишкой, а не всем объектом

они сделают в итоге модуль common

и или relations

они сделают в итоге модуль common

с какого перепуга?

и там будут хранить данные по связям между модулям

это просто подход доведенный до абсолюта в виде фанатичности его следования

ну значит они не умеют в декомпозицию, что ж поделать

это просто подход доведенный до абсолюта в виде фанатичности его следования

common модули запрещены

я понимаю что твой документ правильный

ERROR: S client not available

про модули и про разделение

ты правильно говоришь

и я согласен

"но всеравно все будут херачить как придется"?

не совсем, я на это недеюсь

просто идеального подхода не будет и всегда в команде будут других точек зрений

а представить что все станут сторонниками одного мнения

правильного или неправильного другой, вопрос

это не реально

к сожалению

но я такой же идеалист который бы хотел то о чем ты говоришь

просто я понимаю в реальности от нас мало чего зависит

суть в том что если понадобился функционал в виде аггрегирования данных от разных сущностей

надо решить куда его поместить

или этим будет заниматься фронтенд

или будет монолитный бэкенд и этим заниматься сам

или микросервисы и один агрегатор (по сути такой же бэкенд)

все 3 этих способа ты уже говорил

надо решить куда его поместить

еще один модуль

а ну еще 4 способ модуль один

да

или этим будет заниматься фронтенд

такое тоже бывает

точно

короч

давай по порядку

все зависит от приложения

и надо делать так как подобные вопросы решались

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

если эта ситуация впервые

давай я просто приведу тебе пример реальный

то разработчик делает research

просто я понимаю в реальности от нас мало чего зависит

вспомнил замечательную аналогию, с clean code, про то, как мы должны защищать код и про врача которого пациент торопит не мыть руки, потому что пациент не знает о последствиях, а врач знает