заинтересованным сторонам. DDD также может быть идеальным подходом для сценариев обработки больших объемов сложных данных предприятия, с которыми сложно справится, используя другие методики.
Обзор методик проектирования на основе предметной области представлен в статье «Domain Driven Design Quickly» (Проектирование на основе предметной области, краткий обзор) по адресу http://www.infoq.com/minibooks/domain-driven-design-quickly. Также полезными будут книга Эрика Эванса (Eric Evans) «Domain-Driven Design: Tackling Complexity in the Heart of Software» (Проектирование на основе предметной области: как справляться со сложностями в сердце ПО) (Addison-Wesley, ISBN: 0-321-12521-5) и книга Джимми Нильсона (Jimmy Nilsson)
«Применение DDD и шаблонов проектирования» (Вильямс, ISBN 978-5-8459-1296-1, 0-321- 26820-2).
Многослойная архитектура6
Многоуровневая архитектура обеспечивает группировку связанной функциональности приложения в разных слоях, выстраиваемых вертикально, поверх друг друга. Функциональность каждого слоя объединена общей ролью или ответственностью. Слои слабо связаны, и между ними осуществляется явный обмен данными. Правильное разделение приложения на слои помогает поддерживать строгое разделение функциональности, что в свою очередь, обеспечивает гибкость, а также удобство и простоту обслуживания.
Многослойная архитектура описана как перевернутая пирамида повторного использования,
в которой каждый слой агрегирует ответственности и абстракции уровня, расположенного непосредственно под ним. При строгом разделении на слои компоненты одного слоя могут взаимодействовать только с компонентами того же слоя или компонентами слоя, расположенного прямо под данным слоем. Более свободное разделение на слои позволяет компонентам слои взаимодействовать с компонентами того же и всех нижележащих слоев.
Слои приложения могут размещаться физически на одном компьютере (на одном уровне) или быть распределены по разным компьютерам (n-уровней), и связь между компонентами разных уровней осуществляется через строго определенные интерфейсы. Например, типовое Веб-приложение состоит из слоя представления (функциональность, связанная с UI), бизнесслоя (обработка бизнес-правил) и слоя данных (функциональность, связанная с доступом к данным, часто практически полностью реализуемая с помощью высокоуровневых инфраструктур доступа к данным). Подробно n-уровневая архитектура приложения рассматривается в данной главе позже в разделе N-уровневая / 3-уровненая архитектура.
Рассмотрим общие принципы проектирования с использованием многослойной архитектуры:
Абстракция. Многослойная архитектура представляет систему как единое целое, обеспечивая при этом достаточно деталей для понимания ролей и ответственностей отдельных слоев и отношений между ними.
6 Термины слой (layer) и уровень(tier) часто смешивают. Здесь и далее слой обозначает логическое разделение функциональности, а уровень физическое разворачивание на разных системах (прим. научного редактора).
Инкапсуляция. Во время проектирования нет необходимости делать какие-либо предположения о типах данных, методах и свойствах или реализации, поскольку все эти детали скрыты в рамках слоя.
Четко определенные функциональные слои. Разделение функциональности между слоями очень четкая. Верхние слои, такие как слой представления, посылают команды нижним слоям, таким как бизнес-слой и слой данных, и могут реагировать на события, возникающие в этих слоях, обеспечивая возможность передачи данных между слоями вверх и вниз.
Высокая связность. Четко определенные границы ответственности для каждого слоя и гарантированное включение в слой только функциональности, напрямую связанной с его задачами, поможет обеспечить максимальную связность в рамках слоя.
Возможность повторного использования. Отсутствие зависимостей между нижними и верхними слоями обеспечивает потенциальную возможность их повторного использования в других сценариях.
Слабое связывание. Для обеспечения слабого связывания между слоями связь между ними основывается на абстракции и событиях.
Примерами многослойных приложений могут служить бизнес-приложения (line-of-business, LOB), такие как системы бухгалтерского учета и управления заказчиками; Веб-приложения и Веб-сайты предприятий; настольные или смарт-клиенты предприятий с централизованными серверами приложений для размещения бизнес-логики.
Многослойная архитектура поддерживается рядом шаблонов проектирования. Например, под названием Separated Presentation (Отделение представления) объединяется ряд шаблонов, разделяющих взаимодействие пользователя с UI, представление, бизнес-логику и данные приложения, с которыми работает пользователь. Отделение представления позволяет создавать UI в графических дизайнерах, в то время как разработчики пишут управляющий код. Такое разделение функциональности на роли повышает возможность тестирования поведения отдельных ролей. Рассмотрим основные принципы шаблонов Separated Presentation:
Разделение функциональности. Шаблоны Separated Presentation разделяют функциональность UI на роли; например, в шаблоне MVC имеется три роли: Модель (Model), Представление (View) и Контроллер (Controller). Модель представляет данные (возможно, модель предметной области, которая включает базнес-правила); Представление отвечает за внешний вид UI; Контроллер обрабатывает запросы, работает с моделью и выполняет другие операции.
Уведомление на основе событий. Шаблон Observer (Наблюдатель) обычно используется для уведомления Представления об изменениях данных, управляемых Моделью.
Делегированная обработка событий. Контроллер обрабатывает события,
формируемые элементами управления UI в Представлении.
В качестве примеров шаблонов Separated Presentation рассмотрим шаблон Passive View (Пассивное представление) и шаблон Supervising Presenter (Наблюдающий презентатор), также называемый Supervising Controller (Наблюдающий контроллер).
Основными преимуществами многослойного архитектурного стиля и применения шаблона
Separated Presentation являются:
Абстракция. Уровни обеспечивают возможность внесения изменений на абстрактном уровне. Используемый уровень абстракции каждого слоя может быть увеличен или уменьшен.
Изоляция. Обновления технологий могут быть изолированы в отдельных слоях, что поможет сократить риск и минимизировать воздействие на всю систему.
Управляемость. Разделение основных функций помогает идентифицировать зависимости и организовать код в секции, что повышает управляемость.
Производительность. Распределение слоев по нескольким физическим уровням может улучшить масштабируемость, отказоустойчивость и производительность.
Возможность повторного использования. Роли повышают возможность повторного использования. Например, в MVC Контроллер часто может использоваться повторно с другими совместимыми Представлениями для обеспечения характерного для роли или настроенного для пользователя представления одних и тех же данных и функциональности.
Тестируемость. Улучшение тестируемости является результатом наличия строго определенных интерфейсов слоев, а также возможности переключения между разными реализациями интерфейсов слоев. Шаблоны Separated Presentation позволяют создавать во время тестирования фиктивные объекты, имитирующие поведение реальных объектов, таких как Модель, Контроллер или Представление.
Возможность применения многослойной архитектуры необходимо рассмотреть, если в вашем распоряжении имеются уже готовые уровни, подходящие для повторного использования в других приложения; если имеются приложения, предоставляющие подходящие бизнеспроцессы через интерфейсы сервисов; или если создается сложное приложение и предварительное проектирование требует разделения, чтобы группы могли сосредоточиться на разных участках функциональности. Многослойная архитектура также будет уместна, если приложение должно поддерживать разные типы клиентов и разные устройства, или если требуется реализовать сложные и/или настраиваемые бизнес-правила и процессы.
Обратите внимание на шаблон Separated Presentation, если хотите получить улучшенную тестируемость и упростить обслуживание функциональности UI или отделить задачу создания дизайна UI от разработки управляющего кода. Эти шаблоны также будут полезны, если представление UI не содержит никакого кода обработки запросов и не реализует никакой бизнес-логики.
Архитектура, основанная на шине сообщений
Основанная на шине сообщений архитектура описывает принцип использования программной системы, которая может принимать и отправлять сообщения по одному или более каналам связи, обеспечивая, таким образом, приложениям возможность взаимодействия без необходимости знания конкретных деталей друг о друге. Это стиль проектирования, в котором взаимодействия между приложениями осуществляются путем передачи (обычно асинхронной) сообщений через общую шину. В типовых реализациях архитектуры, основанной на шине сообщений, используется либо маршрутизатор сообщений, либо шаблон Publish/Subscribe (Публикация/Подписка) и система обмена сообщениями, такая как Message Queuing (Очередь сообщений). Многие реализации состоят из отдельных приложений, обмен данными между которыми осуществляется путем отправки и приема сообщений по общим схемам и инфраструктуре. Шина сообщений обеспечивает возможность обрабатывать:
Основанное на сообщениях взаимодействие. Все взаимодействие между приложениями основывается на сообщениях, использующих известные схемы.
Сложную логику обработки. Сложные операции могут выполняться как часть многошагового процесса путем сочетания ряда меньших операций, каждая из которых поддерживает определенные задачи.
Изменения логики обработки. Взаимодействие с шиной реализуется по общим схемам и с применением обычных команд, что обеспечивает возможность вставки или удаления приложений на шине для изменения используемой для обработки сообщений логики.
Интеграцию с разными инфраструктурами. Использование модели связи посредством сообщений, основанной на общих стандартах, позволяет взаимодействовать с приложениями, разработанными для разных инфраструктур, таких как Microsoft .NET и Java.
Шины сообщений используются для обеспечения сложных правил обработки уже в течение многих лет. Такой дизайн обеспечивает подключаемую архитектуру, которая позволяет вводить приложения в процесс или улучшать масштабируемость, подключая к шине несколько экземпляров одного и того же приложения. К разновидностям шины сообщений относятся:
Сервисная шина предприятия (Enterprise Service Bus, ESB). ESB основывается на шине сообщений и использует сервисы для обмена данными между шиной и компонентами, подключенными к шине. Обычно ESB обеспечивает сервисы для преобразования одного формата в другой, обеспечивая возможность связи между клиентами, использующими несовместимые форматы сообщений.
Шина Интернет-сервисов (Internet Service Bus, ISB). Подобна сервисной шине предприятия, но приложения размещаются не в сети предприятия, а в облаке. Основная идея ISB – использование Унифицированных идентификаторов ресурсов (Uniform Resource Identifiers, URIs) и политик, управляющих логикой маршрутизации через приложения и сервисы в облаке.
Косновным преимуществам архитектуры, основанной на шине сообщений, относятся: