Описание диаграмм кодом это пока очень грустно, так как autolayout пока что умеет работать с 4-5 квадратами и 8-10 стрелками. Когда их становится больше, а их всегда больше в реальных диаграммах реальных систем, то ты сначала вынужден тратить кучу времени на написание кода (это всегда дольше, чем в графическом редакторе из готового набора элементов drag'n'drop'ом вытянуть квадратик или стрелочку), а потом еще в 10 раз больше времени на то, чтобы потом все расставить так, чтобы это было хоть сколько-нибудь читаемо.
Также в вашем примере с GetDelivery на С2 и С3 все перемешалось в кучу. Поизучайте, что есть Container и что есть Component и как эти абстракции вкладываются друг в друга на диаграммах. Половина ваших компонент на уровне С3 это на самом деле контейнеры с уровня С2 (если не все вообще). Просто попробуйте запихнуть это в тот же structurizr, поймете о чем я?
Кажется, этот подход больше подходит под термин SSR (Server Side Rendering), нежели SDUI или BDUI (Server Driven User Interface или Backend Driven User Interface). В моем понимании SDUI позволяет определять верстку экранов через конфиг на бэкенде, а не через код на фронте и на этом все. В вашем же случае, если я верно понял, конфигурация верстки не может быть возвращена на фронт если нет данных, то есть имеет место зависимость верстки от данных. Кажется, более правильно было бы в конфигурацию вшивать ссылку на источник данных, а фронт, получая эту конфигурацию уже обращался бы к сервисам за самими данными, которые бы возвращали их в привычном виде. Ну и, конечно, в кофигурации нужны маппинги, позволяющие разложить данные в нужные поля, что можно сделать через переменные, значения которых заполняются из ответа сервиса с данными, а потом эти значения подставляются уже в поля элементов UI
В этой схеме мы видим проблемы разработки «узкого горлышка» — кросс-продуктового модуля Accounts. Ведь у разных бизнес-функциональностей есть свои потребности по работе со счетами: фильтрация по определённым признакам, добавление новых атрибутов к счетам и т. д. Всё это должно выполняться в рамках CR (change request) на команду, которая отвечает за разработку модуля счетов. То есть другим командам придётся становиться в очередь и ожидать выполнения доработки. Я бы назвал эту схему «проблема замедления T2M новой фичи».
А во втором случае не возникает ровно той же проблемы только уже на уровне Accounts Middle Ware?)
Если 1 Middleware App = 1 CRUD Service, то зачем их вообще делить? Либо схема некорректная, либо имеется лишнее звено в цепи. Да и даже если запросы ходят из одного Middleware в несколько CRUD, то кажется, что-то пошло не так, так как вы родили еще один API GW, вернее, в вашем случае несколько API GW. Либо я что-то не так понял ¯\_(ツ)_/¯
Вообще, кажется, идет борьба с симптомами болезни, а не с причиной. На мой взгляд один модуль фронта должен ходить к одному набору методов API, сосредоточенных в одном микросервисе, под которым лежит одна БД (ладно, БД может быть несколько, но это прям редкость), откуда берутся данные. И вся эта конструкция "1 модуль FE + 1 микросервис БЕ + 1 БД" представляют собой 1 бизнес-сервис (можно еще навернуть кэш, хранилище медиаконтента и тд по необходимости). Его можно изолированно крутить, поддерживать и развивать одной независимой командой.
Для объединения нескольких сервисов в продукт их можно обернуть неким максимально глупым API Gateway, обеспечивающим, максимум аутентификацию и авторизацию, но по вызовам он должен быть тупой проксей (также как и в Smart Clients Dumb Pipes, хотя там не совсем про то, но смысл тот же)
Если возникает потребность одному бизнес-сервису ходить к другому за данными, то 2 варианта:
контексты бизнес-сервисов (домены) нарезаны не очень корректно и стоит их пересмотреть
Если с пунктом 1 точно все ок, то не бояться продублировать какие-то данные из одного бизнес-сервиса в другие путем фоновой их передачи (Event Driven Architecture в помощь, как вариант). В случае, если с п.1 ок, то таких данных должно быть минимальное количество и они будут нужны просто справочно.
С пунктом 2 главное не путать где мастер-данные, а где справочные. Чтобы 10 сервисов не обновляли одни и те же данные, а потом гемор с мержом всего этого безобразия. Ну и в мастер-сервисе должна быть скорее всего нормализация данных, а вот в потребителях можно легко хранить все в денормализованном виде, чтоб не мучаться
Если же вы по запросам пользователя в онлайне ходите из N сервисов в M других, то это ужасная связанность и нарушение Low Coupling High Cohesion. По сути вы рождаете распределенный монолит со всеми вытекающими.
Я понимаю, что реальность сурова и так или иначе придется сделать сетевой онлайн вызов одного сервиса другим, но это должно быть скорее исключение, нежели правило
Описание диаграмм кодом это пока очень грустно, так как autolayout пока что умеет работать с 4-5 квадратами и 8-10 стрелками. Когда их становится больше, а их всегда больше в реальных диаграммах реальных систем, то ты сначала вынужден тратить кучу времени на написание кода (это всегда дольше, чем в графическом редакторе из готового набора элементов drag'n'drop'ом вытянуть квадратик или стрелочку), а потом еще в 10 раз больше времени на то, чтобы потом все расставить так, чтобы это было хоть сколько-нибудь читаемо.
Также в вашем примере с GetDelivery на С2 и С3 все перемешалось в кучу. Поизучайте, что есть Container и что есть Component и как эти абстракции вкладываются друг в друга на диаграммах. Половина ваших компонент на уровне С3 это на самом деле контейнеры с уровня С2 (если не все вообще). Просто попробуйте запихнуть это в тот же structurizr, поймете о чем я?
Кажется, этот подход больше подходит под термин SSR (Server Side Rendering), нежели SDUI или BDUI (Server Driven User Interface или Backend Driven User Interface). В моем понимании SDUI позволяет определять верстку экранов через конфиг на бэкенде, а не через код на фронте и на этом все. В вашем же случае, если я верно понял, конфигурация верстки не может быть возвращена на фронт если нет данных, то есть имеет место зависимость верстки от данных. Кажется, более правильно было бы в конфигурацию вшивать ссылку на источник данных, а фронт, получая эту конфигурацию уже обращался бы к сервисам за самими данными, которые бы возвращали их в привычном виде. Ну и, конечно, в кофигурации нужны маппинги, позволяющие разложить данные в нужные поля, что можно сделать через переменные, значения которых заполняются из ответа сервиса с данными, а потом эти значения подставляются уже в поля элементов UI
А во втором случае не возникает ровно той же проблемы только уже на уровне Accounts Middle Ware?)
Если 1 Middleware App = 1 CRUD Service, то зачем их вообще делить? Либо схема некорректная, либо имеется лишнее звено в цепи. Да и даже если запросы ходят из одного Middleware в несколько CRUD, то кажется, что-то пошло не так, так как вы родили еще один API GW, вернее, в вашем случае несколько API GW. Либо я что-то не так понял ¯\_(ツ)_/¯
Вообще, кажется, идет борьба с симптомами болезни, а не с причиной. На мой взгляд один модуль фронта должен ходить к одному набору методов API, сосредоточенных в одном микросервисе, под которым лежит одна БД (ладно, БД может быть несколько, но это прям редкость), откуда берутся данные. И вся эта конструкция "1 модуль FE + 1 микросервис БЕ + 1 БД" представляют собой 1 бизнес-сервис (можно еще навернуть кэш, хранилище медиаконтента и тд по необходимости). Его можно изолированно крутить, поддерживать и развивать одной независимой командой.
Для объединения нескольких сервисов в продукт их можно обернуть неким максимально глупым API Gateway, обеспечивающим, максимум аутентификацию и авторизацию, но по вызовам он должен быть тупой проксей (также как и в Smart Clients Dumb Pipes, хотя там не совсем про то, но смысл тот же)
Если возникает потребность одному бизнес-сервису ходить к другому за данными, то 2 варианта:
контексты бизнес-сервисов (домены) нарезаны не очень корректно и стоит их пересмотреть
Если с пунктом 1 точно все ок, то не бояться продублировать какие-то данные из одного бизнес-сервиса в другие путем фоновой их передачи (Event Driven Architecture в помощь, как вариант). В случае, если с п.1 ок, то таких данных должно быть минимальное количество и они будут нужны просто справочно.
С пунктом 2 главное не путать где мастер-данные, а где справочные. Чтобы 10 сервисов не обновляли одни и те же данные, а потом гемор с мержом всего этого безобразия. Ну и в мастер-сервисе должна быть скорее всего нормализация данных, а вот в потребителях можно легко хранить все в денормализованном виде, чтоб не мучаться
Если же вы по запросам пользователя в онлайне ходите из N сервисов в M других, то это ужасная связанность и нарушение Low Coupling High Cohesion. По сути вы рождаете распределенный монолит со всеми вытекающими.
Я понимаю, что реальность сурова и так или иначе придется сделать сетевой онлайн вызов одного сервиса другим, но это должно быть скорее исключение, нежели правило