Software Architect · Модуль 06
Слои полезны, когда защищают важную логику от деталей: HTTP, базы данных, очередей, SDK и текущего фреймворка.
Clean Architecture · dependency inversion · ports and adapters
Бизнес-правила должны зависеть от языка домена, а не от способа доставки запроса.
Детали должны быть снаружи
Фундамент не должен зависеть от цвета занавесок. Цвет можно поменять, фундамент — почти нет.
Clean Architecture, Hexagonal Architecture и Onion Architecture описывают одну идею: центр системы содержит доменные правила и use cases, внешние слои содержат детали. REST controller, SQL query, Redis cache, Stripe SDK и message broker — важные детали, но не источник бизнес-правил.
Dependency Inversion Principle помогает удерживать направление: высокоуровневая политика зависит от абстракций, а реализации подключаются снаружи. Практически это выглядит как port PaymentGateway и adapter StripePaymentGateway.
Слой должен иметь работу
Пустой коридор между двумя комнатами полезен, если по нему ходят. Если он просто увеличивает путь, это лишняя площадь.
Слой нужен, когда он даёт изоляцию, тестируемость или отдельную скорость изменений. Application layer координирует use case. Domain layer хранит правила и инварианты. Infrastructure layer говорит с внешним миром.
Если слой просто перекладывает параметры из одного метода в другой, он не архитектура, а ceremony. Архитектор должен защищать систему и от отсутствия границ, и от бессмысленной многослойности.
Тестируемость быстро показывает, в правильную ли сторону направлены зависимости.
Пример: создание заказа без базы в unit-тесте
Чтобы проверить рецепт, не нужно каждый раз открывать ресторан. Достаточно кухни и ингредиентов.
Use case CreateOrder получает InventoryPort, PaymentPort и OrderRepository как зависимости. В unit-тесте они заменяются fake-реализациями. Тест проверяет правило: нельзя создать заказ без зафиксированной цены и успешного payment intent.
База данных и HTTP не участвуют в этом тесте. Значит, бизнес-правило отделено от инфраструктуры.
Антипример: Active Record как центр вселенной
Если вся логика живёт в ящике с инструментами, каждый ремонт начинается с поиска нужной отвёртки.
Модель ORM одновременно валидирует бизнес-правила, ходит в сеть, отправляет email, пишет audit log и решает permissions. Кажется удобно, пока система маленькая. Потом любой тест поднимает базу, любое изменение тянет side effects, а домен невозможно переиспользовать.
Проблема не в ORM как таковой. Проблема в том, что инфраструктурная модель стала владельцем бизнес-политики.
- Можно ли проверить главное правило без базы и HTTP? - Какие зависимости текут внутрь, а какие наружу? - Где фреймворк диктует модель домена? - Какие adapters можно заменить без изменения use case?