Я иногда вспоминаю первый софт, который писал, а было это 20 лет назад. Мелкие эксперименты. Например, корпоративные сайты. Я тогда все писал ра Perl и было достаточно удобно - каждая .pl-ка (cgi-скрипт) выполняется в своем процессе, не пересекается с другими, развивается автономно. Правда, не было тестов, а деплой был по F5 в mc. И сразу работает :) Это, конечно, не промышленный софт, но если посмотреть на всю последующую историю работы с промышленным софтом, то можно выделить несколько важных тезисов (и еще пару десятков к этим): 1. Промышленным стандартом стали языки, в которых разрабатывать в рамках отдельных независимых модулей стало сложнее (java/c#). Этому же способствовал и инструментарий IDE. Да и лицензии на application servers стоили как самолет. Даже там, где обычного apache хватало с лихвой. 2. Основной объем сложности находился в окружающем контексте. Те самые пресловутые требования, по кусочкам собираемые с сотен человек, затем зачем-то переводимых с бизнес-языка на технический людьми, которые бизнес знают с чужих слов и код если и писали, то в далеком прошлом. 3. Динамика изменений стала высокой. И совмещая тезисы один и два мы получаем достаточно странную структуру того самого легаси-монолита. То есть монолит нас вроде бы уберегает от того, что при неверном проектировании запросов между сервисами не станет больше (все ж локально), но при этом он же позволяет нам дать слабину и не сильно заморачиваться с проектированием. Но даже, если попробуем построить хороший, модульный монолит (а это возможно только при хорошем понимании бизнес-сущностей, предметной области), то окажется, что мы ее не знаем, потому что см тезис 2. И это несмотря на то, что те самые IDE позволяют нам проводить крутейший анализ и рефакторинг над всей кодовой базой. Только код остается кодом, а семантика зависимостей лежит над ним, в области бизнеса.