В статье «Пример описания многослойной архитектуры, основанной на использовании наборов подслоёв и иерархии моделей данных» рассмотрен подход к построению многослойной архитектуры приложения с использованием трёх слоёв и девяти подслоёв.
Использование такого набора взаимодействующих между собой слоёв и подслоёв даёт возможность максимально детально описать структуру функционала приложения. Продолжая далее этот подход можно детализировать каким именно функционалом наполняются подслои приложения и для наполнения подслоёв использовать архитектурные блоки. Под архитектурным блоком далее будет пониматься типовой функционал определённого подслоя приложения.
Анализируя типовой функционал приложения можно выделить 9 основных архитектурных блоков.
Архитектурный блок | Слой / подслой, в котором находится архитектурный блок |
Application façade | Facade layer façade sublayer |
Application façade logic | Facade layer logic sublayer |
Application logic | Logic layer façade sublayer |
Domain logic | Logic layer logic sublayer |
Логика обработки внешних данных | Facade layer data access sublayer или logic layer data access sublayer |
Persistence façade | Persistence layer façade sublayer |
Persistence logic | Persistence layer logic sublayer |
Persistence connector | Persistence layer data access sublayer |
Клиентские части для взаимодействия с веб-сервисами и внешними источниками частично структурированных (semi-structured) данных | Infrastructure layer |
Таблица 1. Перечень архитектурных блоков и их связь со слоями и подслоями приложения.
В книгах
Фаулер Мартин. Архитектура корпоративных программных приложений. - "Вильямc", 2006.
Marinescu Floyd. EJB design patterns: advanced patterns, processes, and idioms. - New York: John Wiley, 2002.
Nilsson Jimmy. .NET Enterprise Design with Visual Basic .NET and SQL Server 2000. - Sams, 2002.
описаны примеры архитектуры, использующие 5 слоёв.
Фаулер | Marinescu | Nilssen |
Presentation layer | Presentation layer | Consumer layer |
Application controller | Application layer | Consumer helper layer |
Application logic | Services layer | Application layer |
Domain model | Domain layer | Domain layer |
Data source | Persistence layer | Persistence access layer |
Таблица 2. Соответствие между списками слоёв приложения из книг Фаулера, Marinescu, Nilssen.
Такой набор слоёв достаточно точно соответствует приведенному в таблице 1 набору архитектурных блоков. В таблице 3 показано соответствие между списком слоёв приложения из этих книг и списком архитектурных блоков.
Архитектурные блоки | Фаулер | Marinescu | Nilssen |
Application façade | Presentation layer | Presentation layer | Consumer layer |
Application façade logic | Application controller | Application layer | Consumer helper layer |
Application logic | Application logic | Services layer | Application layer |
Domain logic | Domain model | Domain layer | Domain layer |
Логика обработки внешних данных | |||
Persistence façade | Data source | Persistence layer | Persistence access layer |
Persistence logic | |||
Persistence connector |
Таблица 3. Соответствие между списком слоёв приложения из книг Фаулера, Marinescu, Nilssen и списком архитектурных блоков.
Рассмотрим более детально функционал, который реализуют архитектурные блоки.
Фасад приложения (application facade) это набор визуальных форм и обработчиков событий визуальных форм или набор endpoint веб-сервиса и обработчиков запросов/сообщений, полученных от внешних потребителей.
Логика фасада приложения (application facade logic) в первую очередь отвечает за внутренние алгоритмы обработки данных всего слоя и вызов функционала use case из logic layer. Также среди типовой логики подслоя аутентификация и авторизация пользователя, валидация входных данных, полученных от консюмера приложения. В технологии asp.net mvc в этом подслое формируется контент веб-формы с использованием шаблона веб-формы приложения и данных из view model, который веб-сервер отправляет в виде ответа на запрос по url-адресу.
Логика приложения (application logic, точка входа в функционал use case) реализует логику приложения, которая координирует выполнения операций бизнес-логики, внутренней логики приложения и обработки внешних данных.
Логика домена приложения (domain logic) функционал предметной области приложения.
Логика обработки внешних данных используется как при прямом взаимодействии с внешними источниками данных для работы с веб-сервисами и хранилищами частично структурированных (semi-structured) данных, так и при взаимодействии с внешними данными посредством слоя приложения persistence layer (при работе с реляционными базами данных).
Слой persistence layer используется при работе с хранилищами структурированных данных таких как реляционные базы данных.
Persistence façade реализует фасад для доступа к внешним персистентным данным в виде набора dao объектов. Использование такого фасада скрывает от вышележащих слоёв детали реализации доступа к внешним данным.
Persistence logic реализует механизмы извлечения и обработки внешних персистентных данных. Для этого можно использовать разнообразные ORM фреймворки или наборы объектов типа persistence manager.
Persistence connector реализует механизмы для работы с соединениями с реляционными базами данных и для работы с пулами таких соединений. Persistence connector непосредственно взаимодействует с механизмами Data Access API, которые для доступа к данным используют интерфейсы JDBC, ODBC, OLE DB.
Рассмотрим примеры клиентских частей приложения для взаимодействия приложения с веб-сервисами и внешними источниками частично структурированных (semi-structured) данных.
Клиентская часть для взаимодействия приложения с soap веб-сервисом представляет собой прокси объект, который конвертирует полученные в формате soap/xml данные в объекты-сущности своей модели данных data transfer model.
Клиентская часть для взаимодействия приложения с NoSql базой данных MongoDB в качестве прокси объекта использует объект типа MongoClient. Применяя MongoClient и связанные с ним объекты типов MongoServer, MongoDatabase и MongoCollection приложение работает с данными из базы данных MongoDB в своей модели данных persistence model.
В качестве примера, который показывает преимущества детализации архитектуры до уровня слой-подслой, рассмотрим реализацию use case “Создание нового документа”. В примере за счёт использования уровня слой-подслой, показано как можно наиболее оптимально реализовать функционал предусловия use case и функционал use case.
Рассматривается приложение, имеющее визуальный интерфейс пользователя. Use case реализует создание новой сущности типа Document. Сущности этого типа хранятся в базе данных в таблице tblDocuments. Название документа хранится в колонке Title этой таблицы и в поле Title класса Document. Бизнес-логика требует уникальности названия каждого документа в рамках колонки Title в таблице tblDocuments (это является предусловием для выполнения use case). Для обеспечения уникальности названия документа к полю, в котором на форме вводится название документа, привязывается объект-валидатор, который инициирует запрос к базе данных для проверки уникальности введённого на форме названия документа по текущему содержимому колонки Title для всех записей в таблице tblDocuments. В случае не уникальности названия валидатор блокирует механизм создания нового документа и выдаёт на форме сообщение об ошибке. Логика валидации реализует функционал, который архитектурно полностью отвязан от функционала use case создания нового документа. Функционал валидации проходит более простую цепочку вызовов (рисунок 2) через слои и подслои приложения в сравнении с цепочкой вызовов (рисунок 3) при отработке функционала use case.
