Мне кажется что следующая модель роста сложности и борьбы с ней может быть релевантной.

Первое: мы начинаем разрабатывать приложение, без модулей, (монолит да), и поначалу все идет хорошо, но где нибудь через год возникает ощущение что все как то связано сложным и странным образом.

Решение: а давайте организуем код по модулям и как то его упорядочим.

Второе: модульный монолит можно развивать еще какое то время, прежде чем возникнет вторая проблема, трудоемкость изменений (это тоже своего рода сложность, сложность тестирования). Если приложение -- достаточно крупный монолит, количество изменений в единицу времени будет только увеличиваться и также будет увеличиваться время необходимое на тестирование. В итоге процесс выпуска новых релизов начинает болезненно буксовать.

Решение: Микросервисы. То что раньше было (или могло быть) модулями теперь становятся отдельными приложениями (взаимодействующими через API, который нужно разрабатывать дополнительно, что overhead, но оправдано). Таким образом объем тестирования сокращается до отдельного сервиса и его связей (а не всего приложения целиком). Да, разрабатывать микросервисы немного более трудоемко чем модульным монолит (за счет API overhead), но это окупается на большой дистанции.

Третье: как я говорил в статье, модульность вообще (и микросервисы в частности) не снижают общую сложность приложения. Это способ лучше организовать связи и облегчить тестирование и раскатывание изменений. Однако, с ростом приложения общая сложность продолжает возрастать и в какой то момент его развитие стопорится потому что "все слишком сложно", и просто чтобы понять какие и где нужно сделать изменения нужно долго разбираться (иногда месяцами).

Решение: bounded contexts (собственно о чем в бОльшей степени статья). Нужно менять системную архитектуру приложения, вводить границы (ограничивающие сложность) и это уже не может быть сделано только на техническом (инженерном уровне), сам продукт нужно менять что бы такой подход к уменьшению сложности сработал. И добиться этого становится действительно тяжело :)

Мой тезис в том что приложения которые фокусируются на стабильности (literature programming) конечно существуют, но являются редким исключением.

P. S. Рад видеть что за вами не заржавеет, респект ?

Разделение продукта на bounded contexts позволяет снизить сложность за счёт того что каждый такой домен ограничен. И это работает.

Однако, такой подход приводит к тому что не все становится возможным сделать "как хочется", что может вызывать критику и сопротивление. Также, это долгосрочная история, что усложняет дело ещё сильнее.

Выбор языка программирования, СУБД, брокера сообщений, необходимого железа, протокола [...] относятся к ведению архитектора и в подавляющем большинстве случаев являются частью архитектуры. Так же частью архитектуры являются решения по способу реализации наиболее критичных частей системы.

При этом декларативные SQL-запросы почти никогда не относятся к архитектуре (структура запросов, например, избежание JOIN-ов ради данных в кеше — может относиться).

Схема БД иногда относится к архитектуре, а иногда нет. Например, если система разбита на мелкие микросервисы с собственными БД, то схемы этих БД зачастую не относятся к архитектуре — их можно в любой момент переписать и поэтому их структура не важное решение и точно не важнейшее.

И вот чтобы четко выделить архитектуру-архитектуру ПО без бизнеса вообще — ни разу не встречалось. Проекты-то не в воздухе возникают.

А еще Архитектура — это то, каким образом приложение выполняет свое предназначение.

уровень перехода [к архитектуре] был в районе внешнего вида форм

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

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

Зато июнь оживет при виде UMLек с классами или схемами модели данных части одного из продуктов.

Если в Архитектуру заложены определенные принципы, например, «клиентские приложения могут обращаться только к определенным типам микросервисов, но не ко всем», то при наличии модели коммуникации их можно проверять автоматически. Точно так же можно контролировать связи микросервисов и баз данных. Если есть определенные правила дизайна моделей данных, те же правила именования таблиц, то и их тоже можно проверять автоматически

внедрение OKR было однозначно полезным

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