N-уровневая слоистая архитектура

Четыре стандартных слоя

Каноническая n-tier-модель описывает четыре слоя, каждый со своей ответственностью:

Presentation layer — обрабатывает всё, что относится к пользовательскому интерфейсу: парсинг HTTP-запросов, десериализация входных данных, форматирование ответов, аутентификационные токены, согласование контента. Знает о веб-протоколе. Не знает о бизнес-правилах.

Application layer — оркестрирует use case’ы. Последовательно вызывает domain и infrastructure, управляет транзакциями, применяет политику авторизации, публикует события. Знает о потоке use case’а. Не содержит бизнес-логику — делегирует в domain.

Domain layer — содержит бизнес-модель: сущности, value objects, доменные сервисы и правила, управляющие ими. На B2B-платформе «заказ нельзя подтвердить, если у него есть просроченные счета» — это доменная логика. У этого слоя нет знания о базе данных, HTTP-фреймворке или системе очередей.

Infrastructure layer — реализует порты, которые определяют domain и application: репозитории баз данных, отправители email, публикаторы очередей, клиенты внешних API. Знает о технологиях. Не знает о бизнес-правилах.

Strict vs relaxed layering

Strict layering требует, чтобы каждый слой зависел только от непосредственно нижележащего. Presentation вызывает Application; Application вызывает Domain; Domain определяет интерфейсы, которые реализует Infrastructure. Domain не имеет никакого знания о Infrastructure — не импортирует драйвер БД, ORM или классы фреймворка.

Strict layering даёт наиболее сильную изоляцию: domain можно тестировать без базы данных, очередей, внешних сервисов. Его можно понять без знания какой-либо технологии. Это фундамент, на котором строятся hexagonal и clean architecture (эти паттерны — strict layering, доведённый до логического завершения, о них — в unit’ах 04 и 05).

Relaxed layering (также «open layer» architecture) позволяет слою вызывать любой нижележащий слой, не только непосредственно смежный. Presentation может вызвать Domain напрямую, минуя Application. Application может импортировать классы Infrastructure напрямую, а не через интерфейс.

Relaxed layering прагматичен: для простых CRUD-операций application layer не добавляет ценности, и принудительный вызов через него — церемония. Компромисс: relaxed layering легче нарушить незаметно — как только разрешено пропускать слои для удобства, дисциплина размывается, и в итоге presentation импортирует классы репозиториев напрямую.

Что слоистость реально даёт — и какова её стоимость

Конкретные выгоды хорошо поддерживаемой слоистой архитектуры:

Замещаемость — infrastructure можно заменить (новая БД, новый message broker, новый email-провайдер) без изменения domain. Работает только тогда, когда domain layer определяет интерфейс, а infrastructure реализует его.

Независимая тестируемость — domain можно тестировать с чистыми in-memory двойниками. Application layer — с fake infrastructure. Для проверки бизнес-правила не нужен end-to-end тест.

Навигируемость — инженеры знают, где искать каждый тип изменений. Изменение URL-роута: Presentation. Изменение потока use case’а: Application. Изменение бизнес-правила: Domain. Изменение SQL: Infrastructure.

Стоимость: каждое сквозное изменение (добавить поле в сущность, выставить его в API, сохранить в БД) требует затронуть четыре файла в четырёх пакетах. Слоистая архитектура обменивает горизонтальную модульность на вертикальную жёсткость. Добавление функциональности — вертикальный разрез через все слои; архитектура делает этот разрез явным и тем самым несколько утомительным.

Антипаттерн architecture sinkhole

Architecture sinkhole — это сбой, описанный во вступительной истории: слой, не добавляющий ценности и просто проксирующий вызовы в нижележащий слой.

// Сервис — чистый sinkhole — не добавляет ничего
class OrderService {
  async getOrder(id: string) {
    return this.orderRepository.findById(id);  // нулевое преобразование, нулевая логика
  }
  async createOrder(dto: CreateOrderDto) {
    return this.orderRepository.save(dto);  // нулевая валидация, нулевая доменная логика
  }
}

Sinkhole-сервис не просто бесполезен — он вреден. Он добавляет косвенность без ценности. Каждое изменение затрагивает лишний файл. Он приучает команду рефлекторно добавлять методы в сервис, даже когда тому нечего привнести.

Sinkhole — не признак того, что слоистость была ошибкой. Это признак того, что domain layer выхолощен. Если он не содержит реальной логики, application layer нечего оркестрировать, и сервисный слой становится прокси. Исправление — не убрать слои, а вернуть логику туда, где ей место: в domain (урок 03-02 разбирает это подробно как паттерн anemic-domain-model).