Команда меняет способ хранения заказов. Казалось бы, клиент не должен заметить, что вместо одной технологии появилась другая. Но внезапно приходится править интерфейсы, пересматривать расчёт скидок и перепроверять весь путь оплаты. Значит, разные причины изменений оказались слишком тесно связаны.
Layered Architecture пытается разделить обязанности внутри приложения. Полезность её не в количестве прямоугольников на диаграмме. Она в возможности менять одну часть без обязательной реконструкции остальных.
Где проходят разумные границы
Условно можно выделить интерфейс, прикладные сценарии, бизнес-правила и работу с данными. Интерфейс отвечает за взаимодействие с пользователем. Прикладной слой координирует операцию. Бизнес-правила определяют, допустима ли скидка или изменение статуса. Доступ к данным знает технические детали хранения.
В конкретной реализации названия и количество слоёв могут отличаться. Важно другое: бизнес-правило не должно случайно зависеть от того, как сегодня оформлен HTTP-запрос или в какой таблице лежат данные.
Нужна ли отдельная команда на каждый слой?
Нет. Слои — это границы внутри архитектуры, а не указание строить организацию из отдельных отделов. Если каждой маленькой доработке требуется пройти очередь от команды интерфейса к команде сервисов и дальше к команде хранения, архитектура может увеличить координационные расходы.
Лучше, когда команда способна довести продуктовый сценарий до результата, соблюдая границы кода. Наличие уровней не освобождает от ответственности за то, что клиент в конце действительно завершит заказ.
В какой момент слои перестают помогать
Можно довести идею до абсурда: чтобы прочитать одно поле, запрос проходит через пять классов, которые ничего не добавляют, кроме передачи аргументов дальше. Это не изоляция бизнес-логики, а плата за формальное соблюдение схемы.
Иногда чтению нужен оптимизированный путь, отличающийся от сложной модели записи. Иногда приложение достаточно маленькое, и несколько ясных модулей будут проще, чем полный набор уровней. Полезно оценивать стоимость изменения, а не число интерфейсов.
Как проверить эффект
Я бы попросил вспомнить последние существенные изменения. Сколько независимых частей пришлось трогать из-за одной бизнес-задачи? Где возникали ошибки? Можно ли протестировать расчёт скидки без запуска внешних систем? Эти ответы показывают полезность границ лучше презентации.
Неплохо также проверить направление зависимостей: если бизнес-логика зависит от технических адаптеров, замена инфраструктуры всё ещё может протащить изменения внутрь. В таких ситуациях стоит сравнить подход с Ports & Adapters, не превращая его в ещё одну обязательную моду.
Хороший слой стоит дешевле той связанности, которую он устраняет. Если его существование только удлиняет путь каждого изменения, он не приносит бизнесу пользы.