Tkpled.ru

Узористый проект

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

Проблемно-ориентированное проектирование (DDD) (англ. Domain-driven design) — это набор принципов и схем, помогающих разработчикам создавать изящные системы объектов. При правильном применении оно приводит к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит сложная бизнес-логика, устраняющая промежуток между реальными условиями области применения продукта и кодом.[1]

Проблемно-ориентированное проектирование не является какой-либо конкретной технологией или методологией. DDD — это набор правил, которые позволяют принимать правильные проектные решения. Данный подход позволяет значительно ускорить процесс проектирования программного обеспечения в незнакомой предметной области.

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

Данный термин был впервые введен Eric Evans в его книге Domain-Driven Design — Tackling Complexity in the Heart of Software[2]

Содержание

Основные определения

  • Домен (англ. domain) — область знаний. Область знаний, к которой применяется разрабатываемое программное обеспечение.
  • Модель (англ. model) — описывают отдельные аспекты области и могут быть использованы для решения проблемы.
  • Язык описания — используется для единого стиля описания домена и модели.

Концепция

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

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

Ограниченные связи

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

Решение: Точно определить контекст, в котором используется модель. Определить границы использования данной модели и ее характеристики.

Целостность

Когда над проектом работает большое количество людей, то есть тенденция дробить модель на несколько, более мелких, фрагментов. Чем больше людей, тем более значительна данная проблема. В конечном итоге теряется целостность проекта.

Решение: Постоянное объединение кусков кода от различных разработчиков и проверка работоспособности посредством тестирования. Это позволяет держаться всем разработчикам в одной большой концепции.

Взаимосвязь

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

Решение: На этапе проектирования точно обозначьте, что именно выполняет каждая модель и как она взаимосвязана с другими моделями. В конечном итоге у вас должна получиться карта взаимосвязей моделей.

Элементы DDD

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

Контекст

В большинстве систем для предприятий используются крупномасштабные зоны ответственности. В DDD этот высший уровень организации называется ограниченным контекстом. Рассмотрим пример, система биллинга крупной телекоммуникационной компании. Ключевые элементы системы:

Все данные элементы должны быть включены в одну единую систему, которая должна работать без перебоев. Но в данном случае, при проектировании, стоит понимать, что если речь идет о системе уведомлений или о системе безопасности, то говорится совершенно о разных вещах. Системы, в которых не удается разделить и изолировать ограниченные контексты, часто приобретают архитектурный стиль, который имеет красноречивое название «Большой ком грязи» в 1999 г. Брайан Фут (Brian Foot) и Йозеф Йодер (Joseph Yoder).[3]

Сутью проблемно-ориентированного проектирования является конкретное определение контекстов и ограничение моделирования в их рамках.

Сущность

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

Объект-значение

Объект-значение — это свойства, важные в той предметной области, которую вы моделируете. У них, в отличие от сущностей, нет обозначения; они просто описывают конкретные сущности, которые уже имеют обозначения. Полезность объектов-значений состоит в том, что они описывают свойства сущностей гораздо более изящным и объявляющим намерения способом. Стоит всегда помнить, что значение объекта никогда не изменяется на протяжении выполнения всего программного кода. После их создания, внесение поправок невозможно.

Сводный корень

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

Службы

Иногда в предметной области есть операции или процессы, у которых нет обозначения или жизненного цикла. Службы области дают инструмент для моделирования этих концепций. Они характеризуются отсутствием состояния и высокой связностью, часто предоставляя один открытый метод и иногда перегрузку для действий над наборами. Если в поведение включено несколько зависимостей, и нет возможности найти подходящего места в сущности для размещения этого поведения, в этом случае используют службу. Хотя сам по себе термин «служба» в мире разработки перегружен различными значениями, но в данной тематике, это обозначает небольшой класс, не представляющий конкретного человека, место или вещь в проектируемом приложении, но включающий в себя какие-то процессы. Использование служб позволяет ввести многослойную архитектуру, так же интегрировать несколько моделей, что вносит зависимость от инфраструктуры.[4]

Взаимосвязь с другими подходами программирования

Объектно-ориентированное программирование

Хотя по концепции проблемно-ориентированное проектирование не должно быть ограничено какими-либо представлениями, но на практике все равно пользуются сильные стороны объектно-ориентированного программирования. Это использования наследования, инкапсуляции, представления в виде методов и классов. Нужно помнить, что объектно-ориентированный подход программирования может быть применен не только к ООП языкам, таким как Java, C# или C++, но так же и с функциональным — F#, Erlang.

Тестирование

Неотъемлемой частью разработки является тестирование. Оно позволяет быть уверенным в работоспособности разрабатываемого продукта на всех этапах разработки. Практичнее производить разработку посредством автотестов по технике TDD.

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

Инструменты

Примечания

  1. Введение в проблемно-ориентированное проектирование  (рус.). Архивировано из первоисточника 17 сентября 2012. Проверено 30 мая 2012.
  2. Evans, E., Domain-Driven Design — Tackling Complexity in the Heart of Software, 2004, Addison-Wesley
  3. Big Ball of Mud, 1999, Urbana, IL 61801 USA
  4. Domain-Driven Design using Naked Objects, 2009, Pragmatic Programmers

См. также

Литература

  • Нильссон Д. Применение DDD и шаблонов проектирования. Проблемно-ориентированное проектирование приложений с примерами на C# и .NET = Applying Domain-Driven Design and Patterns with Examples in C# and .NET. — М.: «Вильямс», 2008. — С. 549. — ISBN 978-5-8459-1296-1
  • Evans E. Domain-Driven Design - Tackling Complexity in the Heart of Software. — Addison-Wesley, 2004. — С. 529. — ISBN 978-0-3211-2521-7
  • Brian F., Joseph Y. Big Ball of Mud. — Urbana, IL 61801 USA, 1999. — С. 41.

Ссылки

  • Введение в проблемно-ориентированное проектирование (рус.)
  • Официальный сайт DDD (англ.)
  • Принцип персональной ответственности
  • Форум Domain-Driven Design (англ.)
  • Введение в проблемно-ориентированное проектирование (англ.)
  • Qi4j фреймворк для DDD (англ.)
  • Plugger — фреймворк для DDD архитектуры в java приложениях (англ.)
  • JdonFramework — java-фреймворк для DDD (англ.)
  • Jon Jenkins из Clever Labs о важности проблемно-ориентированного подхода (англ.)
  • Eric Evans о DDD — Разработка модели (англ.)
  • Eric Evans о DDD — Стратегия проектирования (англ.)
  • Jimmy Nilsson о проблемно-ориентированном проектировании (англ.)
  • Применение проблемно-ориентированного подхода в web разработке (англ.)
  • Интервью Dan Haywood’s на тему проблемно-ориентированного проектирования (англ.)
  • Брэд Эпплтон (Brad Appleton) о законе Деметры (англ.)
  • Мартин Фаулер (Martin Fowler) описывает схему супертипа слоя (англ.)
  • Роберт С. Мартин о принципах S.O.L.I.D. Principles (Принципы) (англ.)
Видео
  • «Как съесть слона?», Немцов Александр (рус.)
  • Eric Evans' on Defining DDD (англ.)
  • Eric Evans on DDD: Strategic Design (англ.)


Проблемно-ориентированное проектирование.