Как стать автором
Обновить

Пример описания многослойной архитектуры, основанной на использовании наборов подслоёв и иерархии моделей данных

Уровень сложности Средний
Время на прочтение 9 мин
Количество просмотров 12K

Эта статья обобщает и развивает описание многослойной архитектуры, представленное в статьях "Examples of Layered Application Architecture Based on the Use of Sublayers Sets and a Hierarchy of Data Models" и "Layered Application Architecture with a Homogeneous Layer Structure". Рассмотрен подход, позволяющий с единой позиции подойти к описанию основных используемых типов архитектуры приложений.

Основными задачами функционала приложения являются:

  • обеспечение работы пользователя при помощи визуального интерфейса;

  • обработка данных с использованием алгоритмов бизнес-логики;

  • обмен данными с внешними источниками данных;

  • обмен данными с внешними потребителями данных;

  • обеспечение хранения персистентных данных.

Приложение выполняет хотя бы одну из этих задач. Если приложение реализует более одной задачи, то логично будет разбить его на несколько слоёв и каждый слой будет выполнять одну из этих задач.

В наиболее общем случае архитектуру большинства приложений можно представить в виде однозвенного (single-tier) или многозвенного (multi-tier) приложения, в котором каждое звено (tier) представляет собой многослойное (layered) приложение. При помощи multi-tier архитектуру с layered структурой каждого звена (tier) можно описать основные используемые типы архитектур - Client-Server Architecture, Event-Driven Architecture, Pipes and filters Architecture, Service-oriented Architecture, Microservices Architecture.

Функционал single-tier application состоит из 3 основных групп:

  1. Функционал группы layered состоит из набора изолированных слоёв; каждый слой реализует специфические для него функции; взаимодействие происходит однонаправленно между соседними слоями.

  2. Функционал группы cross-cutting может использоваться всеми слоями приложения.

  3. Функционал группы dataflow реализует механизмы переноса данных, используемых приложением:

  • data mapping операции для переноса данных между моделями данных приложения;

  • data binding операции для связывания данных модели данных и визуального интерфейса;

  • data serialization операции для сериализации / десериализации данных при обмене данными с другими приложениями при помощи data transfer channel.

Работа функционала single-tier приложения может быть представлена в виде набора схем:

  • схема взаимодействия между слоями приложения;

  • схема взаимодействия между приложением и внешней инфраструктурой приложения (внешними источниками данных и внешними потребителями данных приложения);

  • схема переноса данных между моделями данных приложения.

Слой приложения состоит из функционала слоя и данных слоя. Данные слоя организованы в виде моделей данных.

Взаимодействие между слоями организовано иерархически: 1) взаимодействие между близлежащими слоями и между подслоями одного слоя происходит однонаправленно; 2) обмен данными между моделями данных близлежащих слоёв происходит двунаправленно.

С каждым слоем связана одна или несколько моделей данных. В общем случае приложение состоит из трёх слоёв - facade layer, logic layer и persistence layer.

Facade layer используется как фасад для доступа к функционалу приложения из других звеньев multi-tier application или из других приложений.

Logic layer реализует бизнес-логику работы приложения.

Persistence layer реализует функционал доступа к хранилищам персистентных данных (persistence data stores).

Каждый слой многослойной архитектуры приложения можно представить в виде набора подслоёв – подслоя фасада (façade sublayer) и одного или нескольких функциональных подслоёв. Подслой представляет собой функциональный блок, который реализует набор функциональных операций.

Facade sublayer - функциональный блок, который реализует фасад слоя и предоставляет доступ к функционалу слоя для вышележащего слоя приложения или для другого приложения.

Logic sublayer - функциональный блок, реализующий логику работы слоя.

Data access sublayer - функциональный блок, реализующий доступ к внешним источникам данных.

Подслой состоит из API подслоя, которое используется для доступа из вышестоящего слоя или подслоя, и функционала подслоя. API подслоя состоит из набора публичных методов, предоставляющих доступ к функционалу подслоя.

Рисунок 1. Структура подслоя
Рисунок 1. Структура подслоя
Рисунок 2. Схема взаимодействия между подслоями одного слоя
Рисунок 2. Схема взаимодействия между подслоями одного слоя

В общем случае приложение может взаимодействовать с набором внешних потребителей (external consumer) и набором внешних источников данных (external data source). External consumer выполняет функции потребителя данных (data consumer) и / или продюсера данных (data producer). External data source выполняет функции data consumer и / или data producer.

External data sources можно разделить на 2 типа – local data sources и remote data sources.

С local data sources приложение взаимодействует напрямую без использования драйверов и библиотек. Примерами local data sources являются local files and shared files in the local network, USB/COM/LPT ports.

Примерами remote data sources являются server databases, FTP servers, directory services (LDAP, Active Directory), web-services, message brokers, email and document storage systems.

Верхняя граница приложения (application upper boundary) разграничивает область функционала приложения и область external consumers. Нижняя граница приложения (application lower boundary) разграничивает область функционала приложения и область external data sources.

В структурной схеме приложения входной интерфейс приложения (application input interface) является шлюзом (gateway) для взаимодействия функционала приложения с external consumers. Примеры application input interface – visual interface (состоит из набора visual form) и data transfer interface (состоит из набора server-side endpoint (server-side socket)). Взаимодействие application input interface с функционалом приложения происходит при помощи генерации событий при действиях, совершаемых external consumers.

Если приложение не взаимодействует с external consumers, то application input interface представляет собой internal interface, который может состоять из набора таймеров и / или внутреннего расписания приложения. Таймеры и расписание запускают на выполнение функционал приложения по заданному в них временному отсчёту.

В структурной схеме приложения выходной интерфейс приложения (application output interface) является шлюзом (gateway) для взаимодействия функционала приложения с remote data sources. Элементами application output interface являются client-side network sockets, библиотеки доступа к источникам внешним данным, драйвера баз данных и драйвера внешних устройств.

Рисунок 3. Структурная схема single-tier приложения и его окружения – application boundaries, external consumer и external data sources
Рисунок 3. Структурная схема single-tier приложения и его окружения – application boundaries, external consumer и external data sources

Полная структурная схема single-tier приложения с учётом набора слоёв и взаимодействия между слоями, границ приложения и интерфейсов приложения представлена на рисунке 4.

Рисунок 4. Структура слоёв и схема  взаимодействия между слоями многослойного приложения
Рисунок 4. Структура слоёв и схема взаимодействия между слоями многослойного приложения

Facade sublayer в любом слое приложения предоставляет доступ извне к функционалу слоя.

Facade sublayer слоя facade layer это набор обработчиков событий визуальных форм или набор обработчиков запросов/сообщений, полученных от внешних потребителей.

Facade sublayer слоя logic layer реализует логику приложения, которая координирует выполнения операций бизнес-логики, внутренней логики приложения и обработки внешних данных. Функционал этого подслоя часто называют application logic.

Facade sublayer слоя persistence layer представляет собой набор объектов для доступа к внешним данным (data access objects).

Logic sublayer в любом слое приложения реализует внутреннюю логику этого слоя.

Функционал logic sublayer может быть связан с необходимостью получения данных из внешних источников данных, которые используются в алгоритмах этого подслоя. Для этого logic sublayer может взаимодействовать с data access sublayer этого же слоя приложения.

Примеры функционала logic sublayer слоя facade layer:

  • формирование контента для отображения на визуальном интерфейсе приложения;
    например в технологии asp.net mvc это функционал, используемый для формирования контента веб-форм с использованием шаблонов визуальных форм (view templates);

  • валидаторы для данных, вводимых пользователем на визуальном интерфейсе приложения; если в поле на визуальной форме требуется ввести значение, уникальное с точки зрения данных, связанных с этим полем в базе данных, то используется объект типа UniqueValueValidator; этот объект, при помощи обращения к data access sublayer, инициирует запрос в базу данных для проверки уникальности вводимого значения;

Logic sublayer слоя logic layer реализует бизнес-логику приложения. Функционал этого подслоя часто называют domain logic. Взаимодействие с data access sublayer этого же слоя приложения возможно в следующих случаях:

  • для извлечения из хранилища данных справочных данных, которые используются в алгоритмах бизнес-логики;

  • в рекурсивных алгоритмах бизнес-логики на каждой итерации рекурсии при необходимости может происходить взаимодействие с хранилищем данных;

Как пример функционала logic sublayer слоя persistence layer можно привести извлечение из хранилища данных справочных данных, которые persistence layer использует для своей работы.

Data access sublayer в любом слое приложения реализует механизмы доступа и обработки внешних данных.

Для façade layer и logic layer доступ к внешним данным возможен тремя путями: 1) прямой доступ к local data sources (local files and shared files в локальной сети); 2) доступ через application output interface (доступ к web-services, message brokers, directory services, email and document storage systems); 3) доступ через persistence layer (доступ к базам данных).

Для persistence layer доступ и обработка внешних данных является основной задачей.

На рисунке 5 приведены структурные схемы архитектуры web-сервиса, report viewer и asp.net mvc приложений.

Рисунок 5. Структурные схемы архитектуры web-сервиса, report viewer и asp.net mvc приложений
Рисунок 5. Структурные схемы архитектуры web-сервиса, report viewer и asp.net mvc приложений

Рассмотрим структуру report viewer приложения. Facade layer распределяет свою функциональность по подслоям следующим образом:

  • facade sublayer представляет собой визуальную форму, которая содержит визуальный компонент report viewer, используемый для отображения контента отчёта.

  • logic sublayer содержит функционал генератора отчётов (report generator) и набор шаблонов отчётов (report templates); генератор отчётов, формирует контент отчёта, используя шаблоны отчётов и внешние данные, полученные от data access sublayer;

  • data access sublayer формирует данные, необходимые для отчёта, при помощи обращения к persistence layer.

    Persistence layer взаимодействует с базами данных.

Рассмотрим структуру web-сервиса. Facade layer распределяет свою функциональность по подслоям следующим образом:

  • facade sublayer представляет собой data transfer interface, реализующий функционал приёма запросов от внешних клиентов сервиса и отправки ответов на запросы;

  • logic sublayer содержит soap или json сериализатор и десериализатор, которые осуществляют трансформацию данных между сообщениями в формате soap или json и объектной моделью веб-сервиса;

  • data access sublayer формирует данные, необходимые для ответа на web-запрос, при помощи обращения к persistence layer.

    Persistence layer взаимодействует с базами данных.

Рассмотрим структуру простейшего asp.net mvc приложения. Facade layer распределяет свою функциональность по подслоям следующим образом:

  • facade sublayer представляет собой набор asp.net mvc контроллеров, которые принимают web-запрос и отправляют сформированный контент в качестве ответа на web-запрос;

  • logic sublayer содержит генератор контента веб-форм (view engine) и набор шаблонов визуальных форм (view templates) при помощи которых формируется контент ответа на web-запрос;

  • data access sublayer формирует данные, необходимые для ответа на web-запрос, при помощи обращения к persistence layer.

    Persistence layer взаимодействует с базами данных.

На примере приложения, использующего технологию asp.net mvc, удобно показать различия в архитектуре, возникающие при изменении функционала приложения.

Рисунок 6. Структурные схемы архитектуры разных asp.net mvc приложений
Рисунок 6. Структурные схемы архитектуры разных asp.net mvc приложений

На левой части рисунка 6 функционал приложения включает авторизацию пользователя при помощи LDAP сервера и бизнес-логику в виде набора CRUD операций для взаимодействия с базами данных.
На правой части рисунка 6 функционал приложения включает авторизацию пользователя при помощи LDAP сервера и бизнес-логику в виде логики домена приложения и набора CRUD операций для взаимодействия с базами данных.

Каждый слой приложения реализует свой специфический набор функционала приложения. В тоже время взаимодействие с внешними данными может происходить из любого слоя.

Как общие, так и специфические функции слоёв можно определить следующим образом.

  1. Facade layer:

  • предоставление данных слоя внешним потребителям данных приложения;

  • внутренняя логика слоя;

  • взаимодействие с внешними хранилищами данных.

  1. Logic layer:

  • предоставление данных слоя вышележащим слоям приложения;

  • внутренняя логика слоя, которая является бизнес-логикой приложения;

  • взаимодействие с внешними хранилищами данных.

  1. Persistence layer:

  • предоставление данных слоя вышележащим слоям приложения;

  • внутренняя логика слоя;

  • взаимодействие с внешними хранилищами данных.

Данные single-tier application можно подразделить на несколько основных групп:

  • facade application data – данные, предоставляемые приложением для внешних потребителей;

  • internal application data – данные специфичные для логики работы приложения (как для бизнес-логики, так и для внутренней логики приложения);

  • external application data – данные, полученные приложением из внешних источников данных;

  • boundary application data – данные на границах приложения при взаимодействии приложения с внешними источниками данных и внешними потребителями данных; это данные в элементах управления визуальных форм или двоичные данные при обмене данными по data transfer channel.

Соответствие слоёв приложения и групп данных приложения:

  • facade application data используются в façade layer;

  • internal application data используются в слое приложения, если в этом слое есть подслой logic sublayer;

  • external application data используются в слое приложения, если в этом слое есть подслой data access sublayer.

Рисунок 7. Схема обмена данными для приложения, реализующего как бизнес-логику, так и взаимодействие с внешними источниками данных
Рисунок 7. Схема обмена данными для приложения, реализующего как бизнес-логику, так и взаимодействие с внешними источниками данных
Рисунок 8. Схема обмена данными для приложения, реализующего только бизнес-логику
Рисунок 8. Схема обмена данными для приложения, реализующего только бизнес-логику
Рисунок 9. Схема обмена данными для приложения, реализующего только взаимодействие с внешними источниками данных
Рисунок 9. Схема обмена данными для приложения, реализующего только взаимодействие с внешними источниками данных

Статья доработана и обновлена 03.03.2023 г.

Теги:
Хабы:
-1
Комментарии 3
Комментарии Комментарии 3

Публикации

Истории

Работа

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн
PG Bootcamp 2024
Дата 16 апреля
Время 09:30 – 21:00
Место
Минск Онлайн
EvaConf 2024
Дата 16 апреля
Время 11:00 – 16:00
Место
Москва Онлайн