Архитектурный слой — это уровень абстракции, который разделяет систему на части (слои), обеспечивая логическую организацию компонентов. Каждый слой отвечает за выполнение конкретных задач и взаимодействует с другими слоями через четко определённые границы слоев.
Пример классической многослойной архитектуры — это разделение на:
- Слой данных (репозитории) — отвечает за взаимодействие с хранилищем данных (базы данных, файлы и др.), абстрагирует механизмы хранения.
- Слой бизнес-логики (сервисы) — реализует ключевую функциональность и бизнес-правила. Не занимается техническими деталями хранения данных или спецификой отображения.
- Слой представления (контроллеры) — обеспечивает внешнему миру интерфейс для доступа к бизнес-логике приложения. Обрабатывает пользовательские запросы, валидирует и подготавливает данные для слоя бизнес-логики.
Правильная многослойная архитектура строится на ряде базовых принципов:
- Чёткое разделение ответственности (Separation of Concerns): Каждый слой должен быть сосредоточен на выполнении одной задачи (например, UI, бизнес-логика, доступ к данным). Например, слой бизнес-логики не должен заниматься задачами, связанными с пользовательским интерфейсом, и наоборот. Это упрощает изменения, поддержку и тестирование.
- Минимизация связности между слоями (Loose Coupling): Взаимодействие между слоями должно происходить через хорошо определённые интерфейсы или API - границы слоев. Это снижает зависимость слоёв друг от друга и облегчает замену или обновление слоёв.
- Инверсия зависимостей (Inversion of Control): Верхние слои не должны зависеть от реализации нижних слоёв. Использование абстракций (интерфейсов) помогает избежать жестких зависимостей и улучшает тестируемость.
- Логика не должна просачиваться между слоями: Каждая бизнес-логика или специфическая реализация должны быть строго в том слое, к которому они относятся, чтобы избежать смешивания задач.
Преимущества такого подхода:
- Модульность: Легче модифицировать или заменять части системы без влияния на весь код.
- Повторное использование: Логика, размещённая в одном слое, может быть использована различными частями системы. Например, у вас один слой бизнес логики, но несколько слоев представления - REST контроллеры и Kafka, бизнес-логика одна, а способов вызова несколько.
- Упрощение тестирования: Благодаря разделению задач, тестирование может быть сосредоточено на отдельных слоях.
Лучшие практики проектирования
Односторонний поток управления. Все вызовы должны идти строго сверху вниз: слой представления → слой бизнес-логики → слой данных. Это гарантирует, что каждая часть системы “видит” только свои зависимости и не накапливает избыточных связей.
Например, контроллеры обращаются только к сервисам, они ничего не знают про репозитории и про то где храняться данные, им это не важно, их задача вызывать бизенс-логику. Если контроллер напрямую вызывает репозиторий, он обходит бизнес-правила и нарушает инверсию зависимостей.
Репозитории не взаимодействуют между собой.
- Каждый репозиторий отвечает только за свой тип данных, за свою таблицу.
- Если один репозиторий начинает вызывать методы другого, это приводит к жесткой связанности.
Севрис взаимодействует только со своим репозиторием. Каждый сервис оперирует исключительно теми данными, за которые отвечает его собственный репозиторий. Это предотвращает неявные связи между доменами и упрощает поддержку.
Типичные ошибки при проектировании слоёв
- Слои как простая формальность: Иногда разработчики создают слои, но не используют их как абстракции. Это приводит к тому, что слои теряют свой смысл и становятся перегруженными логикой, не относящейся к их роли.
- Слишком много слоёв: Перегруженная многослойная архитектура может стать трудной для понимания и сопровождения. Использование слишком большого количества слоёв увеличивает сложность без явных преимуществ.
- Необоснованное использование ORM в слое бизнес-логики: Когда объекты из слоя данных (например, сущности ORM) напрямую используются в бизнес-слое, это нарушает принцип инкапсуляции и ведёт к избыточным зависимостям.
Нарушение инкапсуляции и границ слоёв
Мета информация
Область:: 00 Архитектура ПО
Родитель::
Источник::
Создана:: 2024-09-27
Автор::