47 lines
5.7 KiB
Markdown
47 lines
5.7 KiB
Markdown
|
---
|
|||
|
|
aliases:
|
|||
|
|
- архитектурного слоя
|
|||
|
|
- слой
|
|||
|
|
- слоями
|
|||
|
|
tags:
|
|||
|
|
- maturity/🌱
|
|||
|
|
date: 2024-09-27
|
|||
|
|
zero-link:
|
|||
|
|
- "[[../../meta/zero/00 Архитектура ПО|00 Архитектура ПО]]"
|
|||
|
|
parents:
|
|||
|
|
linked:
|
|||
|
|
---
|
|||
|
|
Архитектурный слой — это уровень абстракции, который разделяет систему на части (слои), обеспечивая логическую организацию компонентов. Каждый слой отвечает за выполнение конкретных задач и взаимодействует с другими слоями через четко определённые интерфейсы.
|
|||
|
|
|
|||
|
|
Пример классической многослойной архитектуры — это разделение на уровни представления (интерфейс пользователя), бизнес-логики (основные процессы) и данных (хранение и управление информацией). Это облегчает разработку, поддержку и масштабирование системы.
|
|||
|
|
|
|||
|
|
Основные идеи использования слоёв в архитектуре:
|
|||
|
|
- **Чёткое разделение ответственности (Separation of Concerns)**: Каждый слой должен быть сосредоточен на выполнении одной задачи (например, UI, бизнес-логика, доступ к данным). Например, слой бизнес-логики не должен заниматься задачами, связанными с пользовательским интерфейсом, и наоборот. Это упрощает изменения, поддержку и тестирование.
|
|||
|
|
- **Минимизация связности между слоями**: Взаимодействие между слоями должно происходить через хорошо определённые интерфейсы или API. Это снижает зависимость слоёв друг от друга и облегчает замену или обновление слоёв.
|
|||
|
|
- **Инверсия зависимостей**: Верхние слои не должны зависеть от реализации нижних слоёв. Использование абстракций (интерфейсов) помогает избежать жестких зависимостей и улучшает тестируемость.
|
|||
|
|
- **Логика не должна просачиваться между слоями**: Каждая бизнес-логика или специфическая реализация должны быть строго в том слое, к которому они относятся, чтобы избежать смешивания задач.
|
|||
|
|
- **Использование принципов** [[SOLID|SOLID]]: Следование принципам объектно-ориентированного проектирования, таким как единая ответственность ([[Single Responsibility Principle|Single Responsibility]]) и открытость/закрытость ([[Open Closed Principle|Open/Closed Principle]]), помогает создать гибкие и легко расширяемые архитектуры.
|
|||
|
|
|
|||
|
|
Преимущества:
|
|||
|
|
- **Модульность**: Легче модифицировать или заменять части системы без влияния на весь код.
|
|||
|
|
- **Повторное использование**: Логика, размещённая в одном слое, может быть использована различными частями системы.
|
|||
|
|
- **Упрощение тестирования**: Благодаря разделению задач, тестирование может быть сосредоточено на отдельных слоях.
|
|||
|
|
|
|||
|
|
Частые ошибки:
|
|||
|
|
- **Слои как простая формальность**: Иногда разработчики создают слои, но не используют их как абстракции. Это приводит к тому, что слои теряют свой смысл и становятся перегруженными логикой, не относящейся к их роли.
|
|||
|
|
- **Слишком много слоёв**: Перегруженная многослойная архитектура может стать трудной для понимания и сопровождения. Использование слишком большого количества слоёв увеличивает сложность без явных преимуществ.
|
|||
|
|
- [[Необоснованное использование ORM в слое бизнес-логики]]: Когда объекты из слоя данных (например, сущности ORM) напрямую используются в бизнес-слое, это нарушает принцип [[Инкапсуляция|инкапсуляции]] и ведёт к избыточным зависимостям.
|
|||
|
|
|
|||
|
|
***
|
|||
|
|
## Мета информация
|
|||
|
|
**Область**:: [[../../meta/zero/00 Архитектура ПО|00 Архитектура ПО]]
|
|||
|
|
**Родитель**::
|
|||
|
|
**Источник**::
|
|||
|
|
**Создана**:: [[2024-09-27]]
|
|||
|
|
**Автор**::
|
|||
|
|
### Дополнительные материалы
|
|||
|
|
-
|
|||
|
|
|
|||
|
|
### Дочерние заметки
|
|||
|
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|