Перейти к основному содержимому

Слоистая архитектура

Слоистая архитектура — архитектурный подход, при котором система разделяется на логические слои. Каждый отвечает за строго определённую группу задач и взаимодействует с другими слоями по правилам.

Идея: разделить ответственность, чтобы изменения в одной части системы не требовали переписывания всей системы.

Применяется в корпоративных системах, backend-приложениях, монолитах и модульных системах.

Базовые принципы​

Разделение ответственности​

Каждый слой решает одну категорию задач:

  • взаимодействие с пользователем или внешними клиентами,,
  • управление бизнес-процессами,
  • бизнес-правила,
  • работа с данными и внешними системами.

Слой не должен брать на себя задачи, не относящиеся к его ответственности.

Однонаправленные зависимости​

Зависимости направлены сверху вниз:

  • верхние слои используют нижние,
  • нижние не знают о верхних.

Это снижает связанность и упрощает изменение системы.

Контракты между слоями​

Контракт слоя — это формальное описание того:

  • какие данные слой принимает,
  • какие данные возвращает,
  • какие ошибки и ограничения возможны.

Контракт важнее реализации.

На практике контракт выражается через:

  • интерфейсы (например, OrderRepository),
  • DTO и входные команды,
  • описанные ошибки и исключения.

Важно:

  • верхний слой знает контракт, но не реализацию;
  • реализацию можно заменить (другая БД, другой внешний сервис), не меняя вызывающий слой.

Изоляция изменений​

Изменения в одном слое не должны затрагивать другие, если контракт сохранён.

Пример:

  • смена базы данных не требует изменений в бизнес-логике;
  • смена UI не влияет на доменные правила..

Типовая структура​

Презентационный слой (Presentation Layer)​

Назначение:

  • принять запрос,
  • проверить формат данных,
  • вернуть результат пользователю или клиенту.

Включает:

  • UI (веб, мобильный, desktop),
  • REST / GraphQL контроллеры,
  • валидацию формата данных.

Не должно быть:

  • бизнес-логики,
  • прямой работы с БД.

Слой приложения (Application / Service Layer)​

Назначение:

  • управлять сценариями использования (use cases),
  • определять последовательность шагов,
  • управлять транзакциями и безопасностью

Включает:

  • сервисы приложений,
  • оркестрация логики,
  • обработку ошибок сценариев.

Отвечает на вопрос: «что именно нужно сделать», но не содержит бизнес-правил.

Бизнес слой (Domain / Business Layer)​

Назначение:

  • реализация бизнес-правил и ограничений,
  • хранение данных предметной области.

Включает:

Ключевой слой, ради которого существует система.

Не должно быть:

  • логики UI,
  • SQL, HTTP-вызовов,
  • технических деталей хранения данных.

Инфраструктурный слой (Infrastructure Layer)​

Назначение

  • реализация технических деталей.
  • работа с БД,
  • интеграции с внешними системами,
  • файловые хранилища, очереди, API, кэш

Включает:

  • репозитории,
  • ORM,
  • HTTP-клиенты,
  • адаптеры.

Взаимодействие слоёв​

Типовой поток запроса:

  1. Presentation Layer принимает запрос
  2. Application Layer запускает сценарий
  3. Domain Layer выполняет бизнес-логику
  4. Infrastructure Layer читает или сохраняет данные
  5. Результат возвращается вверх

Допустимые зависимости​

  • Presentation → Application.

UI не содержит бизнес-логики, а только инициирует сценарии. Это упрощает изменение интерфейсов.

  • Application → Domain.

Слой приложения управляет процессом, бизнес слой — правилами. Логика не дублируется.

  • Domain → интерфейсы инфраструктуры.

Бизнес слой знает абстракции, но не реализации. Обеспечивает независимость от технологий.

Недопустимые зависимости​

  • Presentation → Domain напрямую.

UI начинает управлять бизнес-логикой. При добавлении нового интерфейса логика дублируется.

  • Domain → Presentation.

Бизнес-правила становятся зависимыми от UI. Невозможно использовать домен в другом контексте.

  • Domain → конкретная БД или HTTP-клиент.

Бизнес слой «привязывается» к технологии. Любая смена БД требует переписывания бизнес-логики.

Другие слои​

Могут появляться дополнительные слои:

  • Integration Layer — изоляция внешних API и интеграций
  • Security Layer — авторизация, аутентификация, ACL
  • Caching Layer — работа с кэшем (Redis и аналоги)
  • Messaging / Event Layer — очереди, события, асинхронное взаимодействие

Это не обязательные слои. Их выделяют, если появляется отдельная ответственность. Лишние слои усложняют систему.

Пример​

Банковская система,перевод средств между счетами.

Presentation Layer

  • REST API /transfer
  • Принимает сумму и счета
  • Проверяет формат данных
  • Возвращает результат операции

Application Layer

Сценарий TransferMoneyUseCase

  1. загрузить счета отправителя и получателя,
  2. проверить права пользователя,
  3. вызвать доменную операцию перевода,
  4. сохранить результат.

Domain Layer

  • Сущность Account
  • Бизнес-правила:
    • баланс не может стать отрицательным,
    • перевод возможен только между активными счетами,
    • комиссия рассчитывается по правилам банка

Infrastructure Layer

  • репозиторий счетов (БД),
  • интеграция с антифрод-системой,
  • публикация события о переводе.

Важно:

  • правила перевода находятся только в домене;
  • сценарий описан в application-слое;
  • БД и интеграции можно заменить без изменения логики перевода.

Плюсы и минусы​

  • просто поддерживать: изменения в одном слое минимально затрагивают другие
  • бизнес-логика переиспользуется разными интерфейсами
  • слои тестируются изолированно (юнит-тесты для логики, UI-тесты)
  • можно работать над слоями параллельно
    • дополнительные вызовы снижают производительность. В высоконагруженных системах это может быть критично.
    • риск создания монолита внутри слоя.
    • избыточна для простых проектов или прототипов

Типовые ошибки проектирования​

  • бизнес-логика в контроллерах или репозиториях.
  • сервисный слой без логики (прокси);
  • прямой доступ UI к БД.
  • неясные границы ответственности

Отличия от модульной архитектуры и микросервисов​

Модульная​

Модульная — делит систему по функциональности (Оплата, Доставка). Слоистая — делит систему по типу ответственности.

Они дополняют друг друга: модуль «Оплата» внутри обычно имеет свои слои — UI, application, domain, infrastructure.

Микросервисы​

Микросервисы — физическое разделение на независимые приложения. Слоистая архитектура — логическая структура внутри одного приложения.

Часто каждый микросервис внутри реализован как слоистое приложение. Отличие:

  • сбой слоя данных в монолите влияет на всё приложение;
  • сбой одного микросервиса может не затронуть остальные.

Когда использовать​

Подходит, если:

  • есть нетривиальная бизнес-логика,
  • система будет развиваться,
  • в проекте несколько команд,

Не подходит, если:

  • система одноразовая,
  • минимальная логика,
  • критична каждая миллисекунда задержки.

Материалы​

  1. Междоменные (процессные) инварианты
  2. Слоистая архитектура приложений: как обеспечить поддерживаемость доменного слоя
  3. Слои, Луковицы, Гексогоны, Порты и Адаптеры — всё это об одном
  4. Многоуровневая архитектура
  5. Слоистая архитектура
  6. Архитектура приложения: что это, какие есть виды и как проектировать
  7. Четыре типа архитектуры программного обеспечения
  8. Многослойная архитектура
  9. Чистая архитектура с Typescript: DDD и слоистая архитектура
  10. Слоистая архитектура на основе фреймворка yii
  11. Трехслойная и трехзвенная: введение в архитектуру ИС для аналитика
  12. Многослойная архитектура
  13. Кратко о типах архитектур программного обеспечения, и какую из них выбрали мы для IaaS-провайдера
  14. Многоуровневая архитектура
  15. Архитектура Программного Обеспечения Для Джунов / МОНОЛИТ МНОГОСЛОЙНАЯ МНОГОУРОВНЕВАЯ АРХИТЕКТУРА
  16. Модульная архитектура: что, как и почему?
  17. Многоуровневая клиент-серверная архитектура: принципы и реализация, сревнение с монолитом

Видео​

  1. Слоистая Архитектура на FastAPI / Onion Architecture
  2. Слоистая архитектура. Луковая (onion) архитектура. Слои, изоляция, DI, solid
  3. Архитектура Программного Обеспечения Для Джунов / МОНОЛИТ МНОГОСЛОЙНАЯ МНОГОУРОВНЕВАЯ АРХИТЕКТУРА
  4. Многослойная (многоуровневая) архитектура для системного аналитика
  5. 005. Архитектура и проектирование ПО - Тимур Лукин

Книги​

  1. Архитектура ПО. Руководство для обучающихся архитектурному мышлению - Ганди Раджу, Ричардс Марк, Форд Нил
  2. Идеальная архитектура. Ведущие специалисты о красоте программных архитектур - Диомидис Спинеллис, Георгиос Гусиос
  3. Архитектура программного обеспечения на практике - Л. Басс, П. Клементс, Р. Кацман
  4. Александр Швец. Погружение в Паттерны Проектирования