Многоуровневая архитектура (multilayered architecture) сосредоточена на иерархическом распределении отдельных частей системы при помощи эффективного разделения отношений. Каждая часть соотносится с определённым уровнем (layer), для каждого уровня заданы выполняемые им функции, уровни выстроены в стековую структуру (то есть находятся один поверх другого). Например, типичная многоуровневая архитектура веб-приложения включает уровень представления (компоненты пользовательского интерфейса), уровень бизнес-логики (обработка данных) и уровень доступа к данным. При этом уровень представления считается высшим, за ним идёт уровень бизнес-логики, а за уровнем бизнес-логики – уровень доступа к данным.
Сформулируем основные принципы многоуровневой архитектуры:
1. Проектирование чётко устанавливает разграничение функций между уровнями.
2. Нижние уровни независимы от верхних уровней.
3. Верхние уровни вызывают функции нижних уровней, но при этом взаимодействуют только соседние уровни иерархии.
|
|
Использование многоуровневой архитектуры обеспечивает следующие преимущества:
– Изоляция. Разработка и обновление ПО могут быть изолированы рамками одного уровня.
– Производительность. Распределение уровней на отдельные физические компьютеры повышает производительность и отказоустойчивость.
– Тестируемость. Уровни допускают независимое тестирование.
Многоуровневая архитектура активно применяется при создании бизнес-приложений и сайтов, особенно приложений масштаба предприятия. При этом обычно используется следующий набор уровней (рис. 1):
Уровень представления (presentation layer) ответственен за взаимодействие с пользователем, ввод и вывод информации.
Бизнес-уровень или уровень бизнес-логики (business logic layer) обрабатывает информацию, реализуя конкретные бизнес-правила.
Уровень доступа к данным (data access layer) обеспечивает загрузку и сохранение информации, используя источник данных (файл, база данных) или внешний сервис.
Рис. 1. Типичные уровни бизнес-приложения.
Для каждого уровня дополнительно можно выделить типичный набор компонентов (рис. 2). Заметим, что не все из перечисленных компонентов (и даже уровней) должны присутствовать в любом бизнес-приложении[1].
Рис. 2. Компоненты отдельных уровней.
1. Компоненты пользовательского интерфейса (UI Components). Они предназначены для вывода информации и для ввода данных пользователями. Эти компоненты являются элементами оконного или веб-интерфейса.
2. Компоненты сценариев (UI Process Components). Обычно система подчиняется определённым правилам взаимодействия с ней. Например, в приложении для продажи товаров реализуется следующий сценарий: пользователь выбирает категорию товара из списка категорий, система показывает список товаров, затем пользователь выбирает товар, и система показывает данные по товару. Для того чтобы упорядочить такие сценарии и повторно их использовать, они объединяются в специальные объекты. Кроме этого, создаётся специальный механизм, который позволяет пользователю работать с системой только по определённым сценариям.
|
|
3. Рабочие потоки (Business Workflows). После получения данных от пользователя они должны быть использованы при выполнении бизнес-процессов (рабочих потоков). Бизнес-процессы состоят из шагов, которые должны быть выполнены в определённом порядке. Например, система должна подсчитать общую сумму заказа, проверить данные кредитной карты и организовать доставку товара. При этом заранее неизвестно, сколько времени потребуется на выполнение этих шагов. Поэтому нужен механизм управления этими операциями.
4. Бизнес-компоненты (Business Components). В этих компонентах реализуются бизнес-правила и решаются основные задачи. Другими словами, в них реализуется бизнес-логика приложения. Например, в системе продажи товаров нужно реализовать способ подсчёта общей стоимости покупки и назначить соответствующую плату за доставку.
5. Агенты сервисов (Service Gateways). Когда бизнес-компоненту понадобится функциональность внешнего сервиса, он должен обратиться к некоторому объекту, представляющему этот сервис в системе. На этих агентов часто ложится задача преобразования формата данных внешнего сервиса к формату вызывающего компонента. Например, бизнес-компоненты могут использовать одного агента сервиса для работы с сервисом проверки кредитных карт и другого агента для взаимодействия с сервисом обработки данных от курьера.
6. Интерфейсы сервисов (Service Interfaces). Чтобы сервисы могли воспользоваться функциональностью друг друга, а приложения – функциональностью сервисов, должен быть определён протокол обмена данными и сообщениями между сервисами и приложениями-потребителями. Этот протокол объявляется как интерфейс сервиса. Часто эти интерфейсы называют бизнес-фасадом.
7. Компоненты, отвечающие за доступ к данным (Data Access Components). Программам нужно где-то хранить данные и в какой-то момент выполнения бизнес-процесса к ним обращаться. Имеет смысл абстрагироваться от конкретного вида данных конкретного приложения в пользу универсальных компонентов, представляющих данные. Эти компоненты размещаются в слое доступа к данным. Например, чтобы показать данные о товаре пользователю, приложению понадобится получить данные о товаре из БД. Для этого будет задействован слой доступа к данным и сама БД.
8. Бизнес-сущности (Business Entities). Приложению понадобится передавать данные между компонентами и уровнями. Например, список товаров должен быть передан из слоя доступа к данным в слой представления. Поэтому нужен способ представления в системе бизнес-сущностей из предметной области. Для этого могут использоваться готовые структуры данных или могут быть созданы специальные классы.