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

Слоистая архитектура — подход, при котором система разделяется на логические слои

💚Каждый отвечает за строго определённую группу задач и взаимодействует с другими слоями по правилам


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

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

Каждый слой решает 1 категорию задач:
💚взаимодействие с пользователем/внешними клиентами
💚управление бизнес-процессами
💚бизнес-правила
💚работа с данными и внешними системами

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

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

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

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

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

Контракт слоя — формальное описание:
💚какие данные слой принимает
💚какие данные возвращает
💚какие ошибки и ограничения возможны

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

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

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

Пример:
📍смена БД не требует изменений в бизнес-логике
📍смена 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. Результат возвращается вверх


Другие слои

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

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


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

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

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


📎 Материалы
1. Слоистая архитектура приложений: как обеспечить поддерживаемость доменного слоя
2. Трехслойная и трехзвенная: введение в архитектуру ИС для аналитика
3. Слоистая архитектура
4. Архитектура приложения: что это, какие есть виды и как проектировать

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

#архитектура

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу