интерфейса, однако, как правило, они включают минимальный объем логики приложения, поскольку это может негативно сказаться на удобстве обслуживания и возможности повторного использования, а также усложнить модульное тестирование.

Компоненты логики представления. Логика представления – это код приложения, определяющий поведение и структуру приложения таким образом, что они не зависят от какой-либо конкретной реализации пользовательского интерфейса. Компоненты логики представления, главным образом, обеспечивают реализацию вариантов использования приложения (или пользовательских историй) и координируют взаимодействия пользователя с базовой логикой и состоянием приложения независимо от UI. Также они отвечают за организацию поступающих с бизнес-слоя данных в формат, пригодный для потребления компонентами UI. Например, они могут агрегировать данные из многих источников и преобразовывать их для большего удобства отображения. Компоненты логики представления можно подразделить на две категории:

◦Компоненты Presenter, Controller, Presentation Model и ViewModel. Данные типы компонентов используются при реализации шаблона Separated Presentation и часто инкапсулируют логику представления слоя представления. Чтобы обеспечить максимальные возможности повторного использования и удобство тестирования, эти компоненты не привязаны ни к одному конкретному классу, элементу или элементу управления UI.

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

Более подробно о проектировании слоя представления рассказывает глава 6, «Рекомендации по проектированию слоя представления». Проектированию компонентов представления посвящена глава 11, «Проектирование компонентов представления».

Компоненты слоя сервисов

Приложение может предоставлять слой сервисов для взаимодействия с клиентами или использования другими системами. Компоненты слоя сервисов обеспечивают другим клиентам и приложениям способ доступа к бизнес-логике приложения и используют функциональность приложения путем обмена сообщениями по каналу связи. Обычно в слое сервисов располагаются следующие типы компонентов:

Интерфейсы сервисов. Сервисы предоставляют интерфейс сервисов, в который передаются все входящие сообщения. Описание набора сообщений, которыми необходимо обмениваться с сервисом для осуществления им определенной бизнес-задачи, называется контрактом. Интерфейс сервиса можно рассматривать как фасад, предоставляющий потенциальным потребителям бизнес-логику, реализованную в приложении (как правило, это логика бизнес-слоя).

Типы сообщений. При обмене данными в слое сервисов структуры данных заключены в структуры сообщений, поддерживающие разные типы операций. Например, существуют такие типы сообщений, как Command (Команда), Document (Документ) и другие. Типы сообщений – это контракты сообщений, используемых для взаимодействия потребителей и провайдеров сервиса. Также слой сервисов обычно предоставляет типы данных и контракты, которые определяют типы данных, используемые в сообщениях, и изолируют внутренние типы данных от данных, содержащихся в типе сообщения. Это предотвращает раскрытие внутренних типов данных внешним потребителям, что могло бы привести к сложностям с контролем версий интерфейса.

Более подробно взаимодействие и обмен сообщениями рассматривается в главе 18, «Взаимодействие и обмен сообщениями».

Компоненты бизнес-слоя

Компоненты бизнес-слоя реализуют основную функциональность системы и инкапсулируют соответствующую бизнес-логику. Бизнес-слой обычно включает следующие типы компонентов:

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

Компоненты бизнес-логики. Бизнес-логика – это логика приложения, связанная с извлечением, обработкой, преобразованием и управлением данными приложения; применением бизнес-правил и политик и обеспечением непротиворечивости и действительности данных. Чтобы обеспечить наилучшие условия для повторного использования, компоненты бизнес-логики не должны включать поведение или логику приложения, относящиеся к конкретному варианту использования или пользовательской истории. Компоненты бизнес-логики можно разделить на следующие две категории:

◦Компоненты рабочего процесса. После того как данные введены в компоненты UI и переданы в бизнес-слой, приложение может использовать их для выполнения бизнес-процесса. Многие бизнес-процессы состоят из множества этапов, которые должны осуществляться в соответствующем порядке и могут

взаимодействовать друг с другом посредством механизмов координирования. Компоненты рабочего-процесса определяют и управляют длительными многоэтапными бизнес-процессами и могут быть реализованы с использованием инструментов управления бизнес-процессами. Компоненты рабочего процесса работают с компонентами бизнес-процесса, которые создают экземпляры компонентов рабочего процесса и осуществляют операции с ними. Более подробно компоненты рабочего процесса рассматриваются в главе 14, «Проектирование компонентов рабочего процесса».

◦Компоненты бизнес-сущностей. Бизнес-сущности, или, более обобщенно, бизнес-объекты, инкапсулируют бизнес-логику и данные, необходимые для представления в приложении элементов реального мира, таких как заказчики (Customers) или заказы (Orders). Они сохраняют значения данных и предоставляют их через свойства; содержат и управляют бизнес-данными, которые используются приложением; и обеспечивают программный доступ с сохранением состояния к бизнес-данным и соответствующей функциональности. Также бизнес-сущности проводят проверку содержащихся в них данных и инкапсулируют бизнес-логику для обеспечения непротиворечивости данных и реализации бизнес-правил и поведения. Более подробно компоненты бизнес-сущностей рассматриваются в главе 13, «Проектирование бизнес-сущностей».

Очень часто бизнес-сущности должны быть доступными компонентам и сервисам как бизнесслоя, так и слоя данных. Например, бизнес-сущности могут сопоставляться с источником данных, и к ним могут выполнять доступ бизнес-компоненты. Если слои располагаются на одном уровне, бизнес-сущности могут использоваться совместно непосредственно через указатели. Однако при этом все равно должно быть обеспечено разделение бизнес-логики и логики доступа к данным. Этого можно достичь путем перемещения бизнес-сущностей в отдельную сборку, доступную для использования сборками и бизнес-сервисов, и сервисов данных. Этот подход аналогичен использованию шаблона инверсии зависимостей, когда бизнес-сущности отделяются от бизнес-слоя и слоя данных, и их зависимость от бизнессущностей реализуется как совместно используемый контракт.

Более подробно проектирование бизнес-слоя рассматривается в главе 7, «Рекомендации по проектированию бизнес-слоя». О проектировании компонентов бизнес-слоя рассказывает глава 12, «Проектирование компонентов бизнес-слоя». Проектированию компонентов бизнессущностей посвящена глава 13, «Проектирование бизнес-сущностей». Проектирование компонентов рабочего процесса более подробно обсуждается в главе 14, «Проектирование компонентов рабочего процесса».

Компоненты слоя доступа к данным

Компоненты слоя доступа к данным обеспечивают доступ к данным, размещенным в рамках системы, и к данным, предоставляемым другими сетевыми системами. Обычно слой доступа к данным включает следующие типы компонентов:

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

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

Более подробно проектирование слоя доступа к данным рассматривается в главе 8, «Рекомендации по проектированию слоя доступа к данным». Проектированию компонентов слоя доступа к данным посвящена глава 15, «Проектирование компонентов слоя доступа к данным».

Компоненты сквозной функциональности

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

Компоненты для реализации безопасности. Сюда относятся компоненты,

осуществляющие аутентификацию, авторизацию и валидацию.

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

Компоненты для реализации взаимодействия. Сюда относятся компоненты,

взаимодействующие с другими сервисами и приложениями.

Реализации сквозной функциональности посвящена глава 17, «Сквозная функциональность».