Сейчас сложно найти короткое и понятное определение таких понятий как «слой приложения» и «уровень абстракции». Это влечёт различия в понимании одного и того же либо непонимания данного понятия среди разработчиков. А недопонимания ведут к разногласиям.
Цель этой статьи: совместно выработать определённость, создать у всех единое представление и выработать короткое, ясное и практичное определение для понятия Архитектурный слой в области корпоративных приложений. Всё что приводится в статье вы можете обсудить и дополнить в комментариях, а я актуализирую материал в статье в соответствии с замечаниями.
Архитектурный слой (корпоративного приложения) — это определённый (огранниченный назначением, замкнутый) набор ресурсов (инструментов работы с ресурсами, деталей, составляющих), с помощью которых реализуются множество (огранниченное критериями) прикладных задач, характерных для данного слоя. Вышестоящий слой реализует свои составляющие (ресурсы), на основе ресурсов нижестоящего слоя. Ресурсы определённого слоя совместимы друг с другом и используются только внутри этого слоя (в идеале). Вышестоящий слой может созадавать свои ресурсы используя ресурсы нескольких слоёв. Может иметь отношение к абстрактной, идеализированной системе, сущетвующих в виде схем либо в большей мере относится к реализации — это определяет составляющие слоя.
Составляющие слоя:
Чем характеризуется архитектурный слой:
Коротко о порядке проектирования архитектурных слоёв:
Цель этой статьи: совместно выработать определённость, создать у всех единое представление и выработать короткое, ясное и практичное определение для понятия Архитектурный слой в области корпоративных приложений. Всё что приводится в статье вы можете обсудить и дополнить в комментариях, а я актуализирую материал в статье в соответствии с замечаниями.
Разделение архитектуры корпоративного приложения на слои позволяет
В крупных системах так или иначе слои используются, даже если их так никто не называет.
- лучше выполнять декомпозицию задачи
- проще ориентироваться внутри проекта
- разработчики приобретают возможность внесения изменений в какой-то определённый слой, вместо того, чтобы перерабатывать всё приложение целиком
- помогает структурировать приложения разложением на группы подзадач, находящихся на определенных архитектурных слоях
- в зависимости от уровня сложности слоя, к опыту разработчиков могут быть разные требования, что позволяет распределять разработчиков по слоям в зависимости от опыта
В крупных системах так или иначе слои используются, даже если их так никто не называет.
В чём сейчас заключается путаница при работе с многослойной архитектурой:
Вместо понятий «слой приложения» и «уровень абстракции» пусть используется понятие «Архитектурный слой».
- принято считать, что слоёв должно быть 3: данные, бизнес-логика, интерфейса — но на самом деле слоёв может быть любое необходимое количество
- нет критериев, по которым те или иные задачи относятся к тому или иному слою, что часто приводит, к созданию одного большого прикладного слоя, либо один какой либо из слоёв дорабатывается под задачи, не характерные для него
- нет конкретного короткого определения
- есть пересечения между понятиями слоя (layer), уровня и яруса (tier), к которым так же нет точных определений. По Фаулеру уровни относятся, подразумевая физическое разделение, а на практике такой определённости нет
Вместо понятий «слой приложения» и «уровень абстракции» пусть используется понятие «Архитектурный слой».
Архитектурный слой (корпоративного приложения) — это определённый (огранниченный назначением, замкнутый) набор ресурсов (инструментов работы с ресурсами, деталей, составляющих), с помощью которых реализуются множество (огранниченное критериями) прикладных задач, характерных для данного слоя. Вышестоящий слой реализует свои составляющие (ресурсы), на основе ресурсов нижестоящего слоя. Ресурсы определённого слоя совместимы друг с другом и используются только внутри этого слоя (в идеале). Вышестоящий слой может созадавать свои ресурсы используя ресурсы нескольких слоёв. Может иметь отношение к абстрактной, идеализированной системе, сущетвующих в виде схем либо в большей мере относится к реализации — это определяет составляющие слоя.
Составляющие слоя:
- если слой относится к реализации: классы, объекты, контекст, сервисы, контроллеры, прокси, сборки ...
- если слой относится к абстракции: модели данных (идеализированные), действия...
Чем характеризуется архитектурный слой:
- прикладное назначение, конкретное, логичное, определяет множество задач, которые можно отнести к определённому слою
- определённое множество задач, реализуемых на данном слое
- ресурсы и инструменты, с помощью которых реализуются задачи: данные, объекты и действия, которые можно выполнить над данными и объектами
- данные и логика внутри определённого слоя согласованы внутри себя
- согласованность определяет предсказуемость и предопределённость во взаимодествии ресурсов определённого слоя, другими словами, детали из которых образуется слой совместимы сдруг с другом
- отдельный слой можно воспринимать как единое самодостаточное целое
- зависимость между слоями можно свести к минимуму
- созданный слой может быть основой для нескольких различных вышестоящих слоёв
- при переходе от одного слоя к другому, моделируемые сущности обычно подвергаются преобразованию из одного представления в другое
Коротко о порядке проектирования архитектурных слоёв:
- Выделяется все бизнес требования, которые структурируются по категориям.
- Требования разбиваются на задачи, которые должны решаться приложением.
- Задачи категоризируются и объединяются в группы на основе схожести своего предметного назначения.
- На основе этих категорий выделяется общее назначение архитектурного слоя, в котором будут решатся задачи.
- Решения задач можно представить как алгоритм, или процесс, который обеспечивает желаемый результат. Из всех задач выделяются общие составляющие (детали), из которых они реализуются. (модели и действия над ними). О том как это делается, будет дополнительная статья.
- На основе выделенных составляющих реализуются классы соответствующего слоя и как правило объединяются в одну отдельную сборку.
Примеры
Пример 1.
Модель ISO/OSI
Пример 2.
Стоит задача автоматизировать электронный документооборот, которая подразумевает
Пример 3.
Строительство офиса
1 уровень — задачи по строительству здания, фундамент, возведение стен, кирпичи, цемент
2 уровень — отделка мебелирования, детали — обои, мебель…
3 уровень — логическое распределение помещений, людей, деление на отделы — детали: отделы, рабочие места, помещения
Составляющие (реусуры) слоя, включают в себя объекты (кирпичи, плиты, цемент) и действий над ними (положить, установить).
Один слой предоставляет только набор тех ресурсов, которые ему логически характерны. 3й слой (места, кабинеты, отделы), работает только в рамках этих сущностей и действий. Если мест не хватает, то кабинет не достраивается, но его можно достроить, доработав ниже стоящий слой.
Модель ISO/OSI
Пример 2.
Стоит задача автоматизировать электронный документооборот, которая подразумевает
- выполнение элементарных действий с различными видами документов: подписание, согласование, отправка и другое
- автоматическая фоновая работа в несколько потоков
- управление работой потоков оперативно через пользовательский интерфейс
- обмен данными с другими системами (приём, отправка, конвертирование документов)
Пример 3.
Строительство офиса
1 уровень — задачи по строительству здания, фундамент, возведение стен, кирпичи, цемент
2 уровень — отделка мебелирования, детали — обои, мебель…
3 уровень — логическое распределение помещений, людей, деление на отделы — детали: отделы, рабочие места, помещения
Составляющие (реусуры) слоя, включают в себя объекты (кирпичи, плиты, цемент) и действий над ними (положить, установить).
Один слой предоставляет только набор тех ресурсов, которые ему логически характерны. 3й слой (места, кабинеты, отделы), работает только в рамках этих сущностей и действий. Если мест не хватает, то кабинет не достраивается, но его можно достроить, доработав ниже стоящий слой.