13
Проектирование бизнессущностей
Обзор
Бизнес-сущности хранят значения данных и предоставляют их через свойства. Они содержат и управляют бизнес-данными, которые используются приложением, и обеспечивают программный доступ с сохранением состояния к бизнес-данным и связанной функциональности. Бизнес-сущности также должны проводить проверку содержащихся в них данных и инкапсулировать бизнес-логику для обеспечения непротиворечивости и реализации бизнес-правил и необходимого поведения. Таким образом, правильное проектирование или выбор бизнес-сущностей жизненно важны для обеспечения наилучшей производительности и эффективности бизнес-слоя.
Данная глава поможет разобраться с проектированием компонентов бизнес-сущностей. Она начинается с рассмотрения разных форматов данных и использования данных в приложении. После этого демонстрируется, как выбранный формат определяет возможные пути реализации бизнес-правил. Наконец, представляются варианты дизайна для собственных объектов и рассматривается, как реализовывается поддержка сериализации для разных форматов данных.
Общие принципы проектирования компонентов и компоненты, обычно используемые в слоях приложения, более подробно рассматриваются в главе 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 обеспечивает массу преимуществ с технической точки зрения, таких как удобство в