обслуживании, эта схема должна применяться лишь для сложных предметных областей, для которых процессы моделирования и лингвистического анализа обеспечивают безусловные преимущества при обмене сложной для понимания информацией и формулировании общего видения предметной области.
Обзор методик проектирования на основе предметной области представлен в статье «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/enus/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/enus/library/bb266337.aspx.
Инфраструктуре с открытым исходным кодом NHibernate посвящен сайт «NHibernate Forge» (Кузница NHibernate), который можно найти по адресу http://nhforge.org/Default.aspx.
14
Проектирование компонентов рабочего процесса
Обзор
Во многих сценариях задачи пользователя должны осуществляться в определенном порядке на основании выполнения определенных этапов или удовлетворять ряду базовых бизнесправил. Компоненты рабочего процесса используются для инкапсуляции задач и для согласования шагов, необходимых для их выполнения. Компоненты рабочего процесса также могут поддерживать задачи, зависящие от обрабатываемых данных, таких как данные, вводимые пользователем или динамическими бизнес-правилами, которые определяют бизнес-процесс.
Данная глава обсуждает разные сценарии и предлагает руководство по проектированию компонентов рабочего процесса. Она начинается с рассмотрения того, как реальные сценарии проецируются на ключевые сценарии организации рабочего процесса; это поможет сделать правильный выбор стиля рабочего процесса для создаваемого приложения. Далее демонстрируется, как требования и правила определяют доступные варианты реализации компонентов рабочего процесса. И, в заключение, приводятся рекомендации по проектированию компонентов рабочего процесса с учетом различных доступных вариантов.
Общие принципы проектирования и более подробное описание компонентов, обычно используемых в слоях приложения, можно найти в главе 10, «Рекомендации по проектированию компонентов».
Шаг 1 – Выбор стиля рабочего процесса на основании сценариев
Существует три основных типа стилей рабочего процесса: последовательный, конечный автомат и управляемый данными. При последовательном рабочем процессе выполнение задач состоит из определенного набора этапов. В конечном автомате действия определены как набор состояний и событий, которые обусловливают переходы из одного состояния в другое. В управляемом данными рабочем процессе действия выполняются на основании информации, ассоциированной с данными. Таким образом, первым делом при проектировании компонентов рабочего процесса необходимо понять, какой рабочий процесс
требуется поддерживать. Рассмотрим рекомендации по выбору одного из этих трех базовых стилей рабочего процесса:
Последовательный рабочий процесс. Такой рабочий процесс управляет последовательностью действий и принимает решение о том, какой из этапов будет выполнен следующим. Несмотря на то, что последовательный рабочий процесс может включать ветви и циклы, он предсказуем. Используйте последовательные рабочие процессы, если для реализации определенной задачи требуется выполнять серии заранее определенных шагов; или для таких сценариев как управление системами, координирование операций между компаниями и обработка бизнесправил.
Конечный автомат. Такой рабочий процесс переходит в заданное состояние и ожидает возникновения определенных событий для перехода в другое состояние. Используйте конечный автомат для управляемых событиями сценариев, сценариев пользовательских интерфейсов, таких как интерфейс мастера, или систем обработки заказов, в которых предпринимаемые шаги и процессы зависят от данных заказа.
Управляемый данными рабочий процесс1. В таком рабочем процессе данные документа определяют действия, выполняемые рабочим процессом. Этот стиль подходит для таких задач, как процесс утверждения документов.
Шаг 2 – Выбор способа разработки
Для создания рабочих процессов можно использовать код, языки разметки или их сочетание. Используемый подход зависит от требований, предъявляемых к способу разработки в создаваемом решении. Выбор способа разработки также зависит от того, как приложение будет упаковываться и распространяться. Возможны такие варианты:
Только код. Выбирайте этот вариант, если рабочий процесс не будет сильно меняться со временем; если имеются сложные бизнес-правила, которые тяжело выразить средствами языков разметки; если группе разработки привычнее писать управляемый код, а не создавать разметку в визуальных дизайнерах; или если требуется разрабатывать новые типы рабочих процессов, что невозможно сделать с помощью разметки. Также рабочие процессы, созданные с использованием только кода, просто интегрировать в систему управления исходным кодом.
Разделение кода2. Выбирайте этот вариант, если имеются сложные бизнесправила, инкапсулированные компонентами бизнес-слоя; или если требуется предоставить пользователям или администраторам возможность изменять некоторые аспекты рабочего процесса с помощью дизайнеров рабочих процессов.
1Также известны, как рабочие процессы на базе политик (прим. научного редактора).
2То есть используется и язык разметки, и код (прим. научного редактора).