Somasegar S., Guthrie Scott. Руководство Microsoft по проектированию архитектуры приложений

Подождите немного. Документ загружается.

◦ «Introducing System.Transactions in the .NET Framework 2.0» (Представляем

System.Transactions in the .NET Framework 2.0) по адресу

http://msdn.microsoft.com/en-us/library/ms973865.aspx.

◦ «Transactions in WCF» (Транзакции в WCF) по адресу

http://msdn.microsoft.com/en-us/library/ms730266.aspx.

◦ «Transaction Processing in .NET 3.5» (Обработка транзакций в .NET 3.5) по

адресу http://msdn.microsoft.com/en-us/library/w97s6fw4.aspx.

 Реализация рабочего процесса в компонентах бизнес-слоя более подробно

рассматривается в следующих источниках:

◦ «Introduction to the Windows Workflow Foundation Rules Engine» (Введение в

обработчик правил Windows Workflow Foundation) по адресу

http://msdn.microsoft.com/en-us/library/aa480193.aspx.

◦ «Windows Workflow Foundation» по адресу http://msdn.microsoft.com/en-

us/library/ms735967.aspx.

Проектирование бизнес-

сущностей

Обзор

Бизнес-сущности хранят значения данных и предоставляют их через свойства. Они содержат и

управляют бизнес-данными, которые используются приложением, и обеспечивают

программный доступ с сохранением состояния к бизнес-данным и связанной

функциональности. Бизнес-сущности также должны проводить проверку содержащихся в них

данных и инкапсулировать бизнес-логику для обеспечения непротиворечивости и реализации

бизнес-правил и необходимого поведения. Таким образом, правильное проектирование или

выбор бизнес-сущностей жизненно важны для обеспечения наилучшей производительности и

эффективности бизнес-слоя.

Данная глава поможет разобраться с проектированием компонентов бизнес-сущностей. Она

начинается с рассмотрения разных форматов данных и использования данных в приложении.

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

реализации бизнес-правил. Наконец, представляются варианты дизайна для собственных

объектов и рассматривается, как реализовывается поддержка сериализации для разных

форматов данных.

Общие принципы проектирования компонентов и компоненты, обычно используемые в слоях

приложения, более подробно рассматриваются в главе 10, «Рекомендации по

проектированию компонентов».

Шаг 1 – Выбор способа представления сущностей

На этом этапе рассматриваются разные способы представления бизнес-сущностей и

преимущества и недостатки каждого из них, что поможет сделать правильный выбор

представления для конкретного сценария. Перечислим наиболее распространенные форматы:

 Собственные бизнес-объекты. Это объекты общеязыковой среды выполнения

(common language runtime, CLR), описывающие сущности системы. Для создания

этих объектов может использоваться технология объектно-реляционного

сопоставления (object/relational mapping, O/RM), такая как ADO.NET Entity

Framework (EF) или NHibernate (больше сведений можно найти в разделе

Дополнительные источники в конце данной главы), или их можно создавать

вручную. Собственные бизнес-объекты подходят в случаях, когда требуется

инкапсулировать сложные бизнес-правила или поведение вместе со связанными с

ними данными. Если требуется выполнять доступ к бизнес-объектам через границы

AppDomain (Домен приложения), процесса или физические границы, можно

реализовать слой сервисов, который будет обеспечивать доступ посредством

объектов передачи данных (Data Transfer Objects, DTO) и операций обновления или

редактирования бизнес-объектов.

 DataSet или DataTable. Объекты DataSet – это разновидность базы данных в памяти,

которая обычно очень близко соответствует фактической схеме базы данных.

Объекты DataSet, как правило, используются только, если не используется

механизм O/RM-сопоставления и создается объектно-ориентированное

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

схеме базы данных. DataSet не может расширяться для инкапсуляции бизнес-

логики или бизнес-правил. Несмотря на то, что DataSet могут быть сериализованы в

XML, к ним не должен предоставляться доступ через границы процесса или сервиса.

 XML. Это основанный на стандартах формат для организации структурированных

данных. XML обычно используется для представления бизнес-сущностей, только

если этого требует слой представления или если логика должна работать с

содержимым, исходя из его схемы. Например, система маршрутизации сообщений,

логика которой направляет сообщения на основании некоторых известных

элементов XML-документа. Не забывайте, что использование и обработка XML

может требовать больших объемов памяти.

Шаг 2 – Выбор дизайна бизнес-сущностей

Если принято решение о том, что собственные объекты обеспечат наилучшее представление

бизнес-сущностей, следущим шагом является проектирование этих объектов. Подход,

применяемый к проектированию собственных объектов, зависит от сорта объекта, который

планируется использовать. Например, сущности модели предметной области требуют

глубокого анализа предметной области, тогда как сущности модуля таблицы требуют

понимания схемы базы данных. Рассмотрим общие подходы к проектированию при

использовании бизнес-объектов:

 Модель предметной области (Domain Model) – объектно-ориентированный

шаблон проектирования. Цель проектирования предметной области – определение

бизнес-объектов, которые представляют реальные сущности предметной области.

При использовании модели предметной области бизнес-сущности и сущности

предметной области включают и поведение, и структуру. Иначе говоря, бизнес-

правила и отношения инкапсулированы в модели предметной области.

Проектирование предметной области требует глубокого анализа предметной

области и, как правило, не сопоставляется с реляционными моделями,

используемыми большинством баз данных. Применяйте модель предметной

области, если предметная область содержит сложные бизнес-правила, если

создается насыщенный клиент, и модель предметной области может

инициализироваться и удерживаться в памяти. Модель предметной области не

может применяться при работе с бизнес-слоем, не сохраняющим состояние,

который требует инициализации модели предметной области при каждом запросе.

Более подробно модель предметной области и проектирование на основе

предметной области рассматриваются в разделе «Проектирование на основе

предметной области» далее в данной главе.

 Модуль таблицы (Table Module) – это объектно-ориентрированный шаблон

проектирования. Цель проектирования модуля таблицы – определение сущностей

на основании таблиц или представлений базы данных. Операции, используемые

для доступа к базе данных и заполнения сущностей модуля таблицы, обычно

инкапсулированы в сущности. Однако для осуществления операций с базой данных

и заполнения сущностей модуля таблицы могут также использоваться компоненты

доступа к данным. Применяйте подход с модулем таблицы, если таблицы или

представления базы данных достаточно точно представляют бизнес-сущности,

используемые приложением, или если бизнес-логика и операции касаются одной

таблицы или представления.

 Специальные XML-объекты (Custom XML objects) представляют

десериализованные XML-данные, которые могут обрабатываться кодом

приложения. Объекты являются экземплярами классов, определяемыми

атрибутами, которые сопоставляют свойства классов с элементами и атрибутами

XML-структуры. Microsoft .NET Framework предоставляет компоненты, которые

могут использоваться для десериализации XML-данных в объекты и сериализации

объектов в XML. Используйте специальные XML-объекты, если данные, с которыми

вы работаете, уже поступают в XML-формате (например, XML-файлы или операции

базы данных, возвращающие XML как результирующее множество); если требуется

формировать XML-данные из источника не ХML-данных; или при работе с

документами, доступными только для чтения.

При использовании собственных объектов не обязательно, чтобы проектирование всех бизнес-

сущностей выполнялось по одной схеме. Например, для одного из аспектов приложения со

сложными правилами может потребоваться проектирование на основе модели предметной

области, а все остальное приложение может использовать XML-объекты, модуль таблицы или

объекты предметной области.

Шаг 3 – Определение механизмов сериализации

Должно быть принято решение о способе передачи бизнес-сущностей через границы. В

большинстве случаев для передачи данных через физические границы, такие как AppDomain,

процесс и границы интерфейса сервисов, требуется сериализация данных. Также данные

можно сериализовать при пересечении логических границ, но при этом не забывайте о

производительности. Рассмотрите следующие варианты передачи бизнес-сущностей:

 Предоставление прямого доступа к сериализуемым бизнес-сущностям только в

случае необходимости. Если бизнес-сущности используются другим слоем

приложения, располагающимся на том же уровне, самый простой подход –

предоставить бизнес-сущности для прямого доступа без сериализации. Однако

недостатком такого подхода является установление зависимости между

потребителями бизнес-сущностей и реализацией бизнес-сущностей. Поэтому

применение такого подхода рекомендуется только в том случае, если имеется

возможность напрямую управлять потребителями бизнес-сущностей, и нет

необходимости в удаленном доступе к бизнес-сущностям с других уровней.

 Преобразование бизнес-сущностей в сериализуемые объекты передачи данных.

Чтобы устранить зависимость потребителей данных от внутренней реализации

бизнес-слоя, используйте преобразование бизнес-сущностей в специальные

сериализуемые объекты передачи данных. Объект передачи данных (Data Transfer

Object, DTO) – это шаблон проектирования, используемый для упаковки множества

структур данных в одну структуру для передачи через границы. Объекты передачи

данных также полезны, если потребители бизнес-сущностей используют другое

представление или модель данных, например, уровень представления. Этот подход

позволяет менять внутреннюю реализацию бизнес-слоя без влияния на

потребителей данных и упрощает реализацию контроля версии интерфейсов. Его

применение рекомендуется при потреблении данных внешними клиентами.

 Предоставление XML для прямого доступа. В некоторых случаях бизнес-сущности

могут сериализовываться и предоставляться как XML. .NET Framework обеспечивает

широкую поддержку сериализации XML-данных. Атрибуты бизнес-сущностей

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

Более подробно схемы данных для интерфейсов сервисов рассматриваются в главе 9,

«Рекомендации по проектированию слоя сервисов». Взаимодействию слоев и уровней

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

Проектирование на основе предметной области

Проектирование на основе предметной области (Domain Driven Design, DDD) – это объектно-

ориентированный подход к проектированию программного обеспечения на основе

предметной области, ее элементов и поведения и отношений между ними. Цель такого

проектирования – создание программных систем, которые являются реализацией базовой

предметной области, через описание модели предметной области, представленной на языке

специалистов этой предметной области. Модель предметной области можно рассматривать

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

Для применения DDD необходимо четко понимать предметную область, которую

предполагается моделировать, или иметь способности для овладения такими знаниями. При

создании модели предметной области группа разработки нередко работает в сотрудничестве

со специалистами в данной области. Архитекторы, разработчики и специалисты в

рассматриваемой области обладают разной подготовкой и во многих ситуациях будут

использовать разные языки для описания своих целей, желаний и требований. Однако в

рамках DDD вся группа договаривается использовать единый язык, ориентированный на

предметную область и исключающий все технические жаргонизмы.

В качестве ядра ПО выступает модель предметной области, которая является прямой

проекцией этого общего языка; с ее помощью путем анализа языка группа быстро находит

пробелы в ПО. Создание общего языка – это не просто упражнение по получению сведений от

специалистов и их применению. Довольно часто в группах возникают проблемы с обменом

информацией не только по причине непонимания языка предметной области, но также и из-за

неопределенности языка самого по себе. Процесс DDD имеет целью не только реализацию

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

очередь, положительно сказывается на создаваемом ПО, поскольку модель является прямой

проекцией языка предметной области.

Модель предметной области представляется с помощью сущностей, объектов-значений,

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

крупные области ответственности, называемые Ограниченными контекстами (Bounded

Contexts).

Сущности – это объекты модели предметной области, имеющие уникальный идентификатор,

который остается неизменным при изменении состояния ПО. Сущности инкапсулируют и

состояние, и поведение. Примером сущности может быть объект Customer, представляющий и

сохраняющий состояние определенного клиента и реализующий операции, которые могут

выполняться с этим клиентом.

Объекты-значения – это объекты модели предметной области, используемые для описания

определенных аспектов предметной области. Они не имеют уникального идентификатора и

неизменны. Примером объекта-значения является Transaction Amount (Сумма транзакции) или

Customer Address (Адрес клиента).

Сводные корни – это сущности, логически группирующие взаимосвязанные дочерние

сущности или объекты-значения, управляют доступом к ним и координируют взаимодействия

между ними.

Хранилища отвечают за извлечение и хранение сводных корней, как правило, с

использованием инфраструктуры объектно-реляционного сопоставления (O/RM).

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

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

области. В некоторых случаях определенная функциональность или аспект предметной

области не может быть сопоставлен ни с одним объектом, имеющим определенный

жизненный цикл или идентификатор; такая функциональность может быть объявлена как

сервис предметной области. В качестве примера сервиса предметной области можно привести

сервис установления цен каталога товаров системы электронной торговли.

Чтобы сделать модель строгой и полезной языковой конструкцией, как правило, приходится

интенсивно использовать изоляцию и инкапсуляцию в рамках модели предметной области.

Это может обусловить относительную дороговизну системы, основанной на DDD. Несмотря на

то, что 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).

Дополнительные источники

Электронная версия списка используемых источников доступна по адресу

http://www.microsoft.com/architectureguide.

 Более подробно шаблоны, используемые для проектирования бизнес-сущностей,

рассматриваются в статье «Enterprise Solution Patterns Using Microsoft .NET» по

адресу http://msdn.microsoft.com/en-us/library/ms998469.aspx.

 Проектированию бизнес-сущностей посвящена статья «Integration Patterns»,

которую можно найти по адресу http://msdn.microsoft.com/en-

us/library/ms978729.aspx.

 Больше информации о проектировании на основе предметной области можно

найти в следующих источниках:

◦ «An Introduction To Domain-Driven Design» по адресу

http://msdn.microsoft.com/en-us/magazine/dd419654.aspx.

◦ «Domain Driven Design and Development in Practice» по адресу

http://www.infoq.com/articles/ddd-in-practice.

 Более подробно шаблоны, применяемые для проектирования бизнес-слоя,

рассматриваются в статье «Service Orientation Patterns» (Сервисно-ориентированные

шаблоны) по адресу http://msdn.microsoft.com/en-us/library/aa532436.aspx.

 ADO.NET Entity Framework подробно рассматривается в статье «The ADO.NET Entity

Framework Overview» (Обзор ADO.NET Entity Framework) по адресу

http://msdn.microsoft.com/en-us/library/aa697427(VS.80).aspx.

 Больше сведений о проектировании бизнес-сущностей с использованием Microsoft

Dynamics можно найти в статье «Business Entities» (Бизнес-сущности) по адресу

http://msdn.microsoft.com/en-us/library/ms940455.aspx.

 Больше сведений о моделировании бизнес-сущностей с использованием Microsoft

Dynamics можно найти в статье «Modeling Entities» (Моделирование сущностей) по

адресу http://msdn.microsoft.com/en-us/library/aa475207.aspx.

 Более подробно использование бизнес-сущностей в Office Business Applications

(OBA) рассказывает статья «Building Office Business Applications» (Создание офисных

бизнес-приложений) по адресу http://msdn.microsoft.com/en-

us/library/bb266337.aspx.

 Инфраструктуре с открытым исходным кодом NHibernate посвящен сайт

«NHibernate Forge» (Кузница NHibernate), который можно найти по адресу

http://nhforge.org/Default.aspx.

Проектирование компонентов

рабочего процесса

Обзор

Во многих сценариях задачи пользователя должны осуществляться в определенном порядке

на основании выполнения определенных этапов или удовлетворять ряду базовых бизнес-

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

согласования шагов, необходимых для их выполнения. Компоненты рабочего процесса также

могут поддерживать задачи, зависящие от обрабатываемых данных, таких как данные,

вводимые пользователем или динамическими бизнес-правилами, которые определяют

бизнес-процесс.

Данная глава обсуждает разные сценарии и предлагает руководство по проектированию

компонентов рабочего процесса. Она начинается с рассмотрения того, как реальные сценарии

проецируются на ключевые сценарии организации рабочего процесса; это поможет сделать

правильный выбор стиля рабочего процесса для создаваемого приложения. Далее

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

компонентов рабочего процесса. И, в заключение, приводятся рекомендации по

проектированию компонентов рабочего процесса с учетом различных доступных вариантов.

Общие принципы проектирования и более подробное описание компонентов, обычно

используемых в слоях приложения, можно найти в главе 10, «Рекомендации по

проектированию компонентов».

Шаг 1 – Выбор стиля рабочего процесса на основании сценариев

Существует три основных типа стилей рабочего процесса: последовательный, конечный

автомат и управляемый данными. При последовательном рабочем процессе выполнение

задач состоит из определенного набора этапов. В конечном автомате действия определены

как набор состояний и событий, которые обусловливают переходы из одного состояния в

другое. В управляемом данными рабочем процессе действия выполняются на основании

информации, ассоциированной с данными. Таким образом, первым делом при

проектировании компонентов рабочего процесса необходимо понять, какой рабочий процесс

требуется поддерживать. Рассмотрим рекомендации по выбору одного из этих трех базовых

стилей рабочего процесса:

 Последовательный рабочий процесс. Такой рабочий процесс управляет

последовательностью действий и принимает решение о том, какой из этапов будет

выполнен следующим. Несмотря на то, что последовательный рабочий процесс

может включать ветви и циклы, он предсказуем. Используйте последовательные

рабочие процессы, если для реализации определенной задачи требуется выполнять

серии заранее определенных шагов; или для таких сценариев как управление

системами, координирование операций между компаниями и обработка бизнес-

правил.

 Конечный автомат. Такой рабочий процесс переходит в заданное состояние и

ожидает возникновения определенных событий для перехода в другое состояние.

Используйте конечный автомат для управляемых событиями сценариев, сценариев

пользовательских интерфейсов, таких как интерфейс мастера, или систем

обработки заказов, в которых предпринимаемые шаги и процессы зависят от

данных заказа.

 Управляемый данными рабочий процесс

. В таком рабочем процессе данные

документа определяют действия, выполняемые рабочим процессом. Этот стиль

подходит для таких задач, как процесс утверждения документов.

Шаг 2 – Выбор способа разработки

Для создания рабочих процессов можно использовать код, языки разметки или их сочетание.

Используемый подход зависит от требований, предъявляемых к способу разработки в

создаваемом решении. Выбор способа разработки также зависит от того, как приложение

будет упаковываться и распространяться. Возможны такие варианты:

 Только код. Выбирайте этот вариант, если рабочий процесс не будет сильно

меняться со временем; если имеются сложные бизнес-правила, которые тяжело

выразить средствами языков разметки; если группе разработки привычнее писать

управляемый код, а не создавать разметку в визуальных дизайнерах; или если

требуется разрабатывать новые типы рабочих процессов, что невозможно сделать с

помощью разметки. Также рабочие процессы, созданные с использованием только

кода, просто интегрировать в систему управления исходным кодом.

 Разделение кода

. Выбирайте этот вариант, если имеются сложные бизнес-

правила, инкапсулированные компонентами бизнес-слоя; или если требуется

предоставить пользователям или администраторам возможность изменять

некоторые аспекты рабочего процесса с помощью дизайнеров рабочих процессов.

Также известны, как рабочие процессы на базе политик (прим. научного редактора).

То есть используется и язык разметки, и код (прим. научного редактора).