Бойлерплейт — это не зло

Ты наверняка слышал: «Зачем столько кода ради простой задачи?», «Почему нельзя просто взять и написать?», «Эта ваша архитектура только усложняет». Обычно это говорят, когда впервые сталкиваются с бойлерплейтом: DTO, мапперы, слои, разделение моделей. И я их понимаю. Потому что у меня была та же реакция.

Когда я впервые начал работать с более строгой архитектурой, это раздражало. Ты добавляешь одно поле и меняешь несколько классов: DTO, мапперы и ещё пару слоёв. И возникает ощущение: «Я пишу в 3 раза больше кода ради той же задачи». И на короткой дистанции это правда.

Особенно если ты до этого работал, например, с Active Record, когда модель = всё, логика прямо внутри, данные, валидация, поведение — всё в одном месте. Ты просто пишешь и всё работает, быстро, удобно, без лишнего. Проблема начинается не сразу. Она начинается тогда, когда система растёт.

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

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

И вот здесь становится понятно, зачем нужен бойлерплейт. Когда у тебя есть структура, домен отделён, инфраструктура изолирована, есть модели каждого слоя, есть маппинг, смена источника данных не ломает систему. Ты меняешь только инфраструктурный слой. Остальное остаётся нетронутым. И это ключевая идея, бойлерплейт это не "писать больше кода", бойлерплейт - это "ограничить зону изменений".

Теперь про уровень абстракции. Многие воспринимают его как «усложнение». На практике это просто другой уровень работы. Ты перестаёшь думать "как сохранить в базу", и начинаешь думать "что такое сущность", "какие у неё правила", "как система должна себя вести". Инфраструктура уходит на второй план, на первый план выходит поведение системы. Да, цена за это дополнительный код. Но это код, который делает систему предсказуемой, упрощает изменения и снижает количество ошибок в перспективе.

Бойлерплейт особенно важен в команде. Потому что повторяемость = предсказуемость. Когда структура одинакова, новый разработчик быстрее встраивается, проще читать код, проще делать ревью. Он не думает "как тут всё устроено", он уже это знает. И вот здесь происходит перелом в мышлении. Сначала ты думаешь "зачем столько шаблонного кода", потом понимаешь "хорошо, что он везде одинаковый". Да, бойлерплейт можно частично автоматизировать через кодогенерацию, шаблоны и AI. И это нормально. Потому что его цель - зафиксировать структуру.

И последнее. Архитектура — это не усложнение. Это контроль. Если у тебя маленький проект, да, можно проще. Но как только система начинает расти, хаос становится дороже, чем лишний код. Если коротко, без структуры ты быстрее на старте. Со структурой ты быстрее на дистанции. И выбор всегда один и тот же, быстро сейчас или стабильно потом. Бойлерплейт это плата за стабильность. И если ты это принимаешь, ты начинаешь писать код, который живёт дольше, чем одна фича.