Многоуровневая архитектура

Многоуровневая архитектура (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). Приложению понадобится передавать данные между компонентами и уровнями. Например, список товаров должен быть передан из слоя доступа к данным в слой представления. Поэтому нужен способ представления в системе бизнес-сущностей из предметной области. Для этого могут использоваться готовые структуры данных или могут быть созданы специальные классы.