Сколько копий сломано в спорах про правильную организацию и декомпозицию кода. Тут намешаны и архитектурные слои, и ограниченные контексты, и между микросервисами и монолитами...

Мне же видится, что все подходы - это проявления встреченного когда-то в книге по объектно-ориентированному проектированию простого принципа "непрерывности" кода.

Еще помните что такое непрерывность? вот это самое - "для любого эпсилон больше нуля существует дельта, такая, что ...". Эта нудная и формальная математическая формулировка скрывает простую суть: у непрерывных функций малые изменения параметров приводят к малому изменению значения. У "непрерывного кода" похожее свойство - малые изменения требований приводят к малым изменениям кодовой базы.

Казалось бы, что может быть проще? Но, как говорится, есть нюанс. Что такое "малые изменения требований" каждый стейкхолдер понимает по своему. Для кого-то это смена используемой СУБД на другую (подумаешь, изменилась одна строчка в ТЗ!) - и вот для обеспечения непрерывности кода нужно использовать СУБД-независимую прослойку и добро пожаловать в ORM. "Малое изменение" в другом случае - это изменение атрибутивного состава сущностей - и вот мы уже на пути генерации интерфейсных форм по описанию модели.

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

Выделение ограниченных контекстов в DDD и разбиение кодовой базы на части по контекстам тоже, в общем-то, базируется на этом принципе, но идет еще немного дальше. Грамотно построенные границы контекстов ограничивают распространение изменений не только кода, но и требований. Теоретически, изменения в одном контексте не должны бесконтрольно расползаться по соседним контекстам и, соответственно, не затрагивать соответствующую кодовую базу. Хотя, честно говоря, вблизи такого идеального разбиения я пока не встречал 😉.