Слоистая архитектура и её проблемы
↑ 8.2 Архитектурные стили и DDD · → Следующая
Зачем это на собесе
Базовый вопрос архитектуры: что такое N-tier, где она ломается и что предлагают взамен.
Объяснение
Классическая слоистая (N-layer) архитектура: Presentation → Business (Application/Domain) → Data Access → БД. Зависимости направлены сверху вниз.
| Слой | Ответственность |
|---|---|
| Presentation | контроллеры, UI, DTO |
| Business/Service | правила и сценарии |
| Data Access | репозитории, ORM |
| Database | хранение |
Плюсы: простота, знакомая структура, разделение технических ответственностей.
Проблемы:
| Проблема | Пояснение |
|---|---|
| Зависимость домена от БД | бизнес-логика зависит от слоя данных, тесты требуют БД |
| Анемичная модель | вся логика в сервисах, сущности пусты |
| «Сквозной» код | изменение фичи затрагивает все слои (Shotgun Surgery) |
| Раздувание сервисов | OrderService на тысячи строк |
| Слой как способ группировки | папки Controllers/Services/Repositories скрывают предметную область |
| Тесты | без абстракций сложно изолировать |
| Пропуск слоёв | UI обращается напрямую к БД |
Ответы индустрии: инвертировать зависимости (Clean/Hexagonal), группировать по фичам (Vertical Slice), выделять модули, обогащать домен (DDD).
Нюансы и подводные камни
- Для небольших CRUD-приложений слоистая архитектура вполне достаточна — не усложняйте.
- Строгие слои без правил зависимостей вырождаются: закрепляйте архитектурными тестами.
- Число слоёв не равно качеству архитектуры.
Практика
- Нарисуйте зависимости вашего проекта и найдите нарушения (слой → вверх).
- Возьмите одну фичу и посчитайте, сколько файлов в скольких слоях она меняет.
Вопросы с ответами
Главная проблема слоистой архитектуры?
Направление зависимостей: домен зависит от инфраструктуры, а технические слои размывают предметную область.
Когда слои достаточны?
Для простых CRUD-сервисов с малой бизнес-логикой.