Небольшая система часто начинается просто: экран вызывает код, код работает с базой, всё находится рядом и быстро меняется.
Проблема появляется позже, когда бизнес-правила, интерфейс, интеграции и данные начинают зависеть друг от друга настолько, что любое изменение требует осторожно трогать сразу несколько частей системы.
Layered Architecture пытается разделить эти виды ответственности.
Какую проблему мы решаем
Система делится на уровни: например, интерфейс, прикладную логику, бизнес-правила и доступ к данным. Конкретное количество и названия не так важны, как сама идея границ.
Если меняется база данных, это не должно автоматически менять бизнес-логику. Если появляется новый интерфейс, не нужно заново реализовывать правила продукта.
Цель — уменьшить радиус одного изменения.
Что получает бизнес
Для бизнеса ценность слоёв — в более предсказуемой стоимости изменений.
Когда части системы разделены по ответственности, новая интеграция, интерфейс или замена инфраструктурного компонента реже превращается в переписывание всего продукта.
Это особенно важно для систем, которые должны жить долго. Архитектура начинает защищать не текущую скорость разработки, а способность компании менять продукт через год, три или пять.
Но выгода появляется только тогда, когда границы отражают реальные типы изменений. Формальные слои ради самой схемы денег не экономят.
Что получает команда
Команде проще понимать, где находится конкретная ответственность и какой код можно менять, не затрагивая остальное.
Снижается количество случайных зависимостей. Тестировать бизнес-правила можно отдельно от базы данных или пользовательского интерфейса.
Но слишком строгая слоистость может дать обратный эффект: простое поле проходит через пять классов, а небольшое изменение требует десятка формальных преобразований.
Что получает клиент
Клиент обычно не замечает слои напрямую. Он получает более стабильный продукт, в котором внутренние изменения реже ломают соседние функции.
А если команде проще менять систему, новые возможности можно выпускать без постоянного страха затронуть не связанную с задачей часть продукта.
Чем мы за это платим
Цена — дополнительная структура и дисциплина.
Появляются интерфейсы между слоями, преобразование моделей и правила направления зависимостей. Если система маленькая, эта структура может стоить дороже проблем, которые она должна предотвращать.
Есть и организационный риск: архитектура становится догмой, а команда начинает защищать «правильные слои» вместо простоты продукта.
Когда layered architecture не нужна
Для небольшого приложения с простой логикой и коротким жизненным циклом прямой код может быть дешевле и понятнее.
Не нужно создавать четыре слоя только потому, что так нарисовано в учебнике.
Что стоит спросить перед решением
- Какие части системы меняются по разным причинам?
- Какие изменения сегодня затрагивают слишком много кода?
- Нужно ли нам менять интерфейс, данные и бизнес-правила независимо?
- Не создаём ли мы больше переходов, чем реальной изоляции?
- Помогают ли границы новым разработчикам понимать систему?
В итоге
Layered Architecture — не про обязательное количество уровней. Она про то, чтобы разные причины изменений не были намертво склеены.
Для бизнеса хороший слой — тот, который делает будущие изменения локальнее и дешевле. Плохой — тот, который просто добавляет ещё один файл между двумя уже понятными частями системы.