Я участвовал в нескольких запусках продуктов как разработчик. Мантра старших коллег была примерно такой: «Нужно быстро запуститься — срезаем углы везде, где можно».

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

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

Мне было интересно копаться в архитектуре, поэтому я стал разбираться, как строить приложение, в котором можно быстро что-то менять и добавлять, не переделывая каждый раз половину кода. И вуаля — на помощь пришёл модульный монолит. Спасибо дяде Бобу за Clean Architecture, а ещё DDD и Event Driven подходу.

Для себя я сформулировал правила так: (Упрощенно) • Разделяем приложение на модули по зонам ответственности. • Внутри модулей задаём правила для зависимостей: Controller/Presenter → Use Cases → Repository. Логика сценариев не должна зависеть от деталей интерфейса или хранения данных. • Взаимодействие между модулями делаем явным. Мне нравится использовать "события", когда они здесь уместны.

В результате становится понятнее, куда добавлять новую логику, что затронет изменение и что нужно протестировать. Конечно, архитектура не спасает от любого техдолга и не гарантирует, что соседние модули никогда не придётся менять. Но она помогает не превратить каждую новую фичу в раскопки по всему проекту.

Сначала это может выглядеть как overengineering. Зачем столько правил, если надо просто запуститься? По моему опыту, когда команда понимает эти правила, работать внутри проекта становится быстрее и спокойнее.

А теперь появился ещё и ИИ. Раньше я собирал эту структуру руками, а сейчас могу поручить ему всю часть реализации. Моя роль — пинать его, когда он тащит логику не в тот слой, нарушает границы модулей или придумывает лишнюю абстракцию. И, конечно, проверять, что код вообще делает то, что нужно.

В общем, для меня модульный монолит на старте продукта — must-have. Не потому, что он решит все проблемы, а потому, что даёт шанс сохранить скорость после первого релиза.