Доменная модель в проблемно-ориентированном проектировании

Перевод статьи What is the Domain Model in Domain Driven Design?

Если вы следили за Building Cribb, вам, вероятно, уже известно о том, что Domain Driven Design имеет много терминологии.

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

Domain Model это термин, который много раз встречается в Domain Driven Design. Я думаю, что Domain Model является одним из самых очевидных примеров терминологии, что абсолютно ничего не означает, если вы не понимаете контекст, в котором он применяется.

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

Домен —  это проблема

Domain Driven Design основывается вокруг  идеи решения  проблем организации с помощью кода. Это достигается путем фокусировки вложения ресурсов в самом сердце бизнес-логики приложения.

Поэтому домен — это мир бизнеса. Всякий раз, когда вы слышите фразу «Domain Driven Design», вы должны думать о нем, как » Business Problem Driven Design».

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

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

Модель — это ваше решение

Модель Domain Driven Designed project – это ваше решение проблемы. Модель, как правило, представляет собой аспект реальности или какой-то интерес. Модель также часто упрощает общую картину и таким образом важные аспекты решения сосредотачиваются в то время, когда все остальные игнорируются.

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

The Domain Model

Так что означает Domain Model, если Domain —  это мир бизнеса, а Model — это ваше решение? Domain Model – это организованное и структурированное знание проблемы. Domain Model должен представлять собой словарный запас и ключевые понятия предметной области, и он должен определить отношения между всеми субъектами в рамках домена.

Domain Model может быть схемой, примером кода или даже письменной документацией проблемы. Главное, чтобы Domain Model  была доступной и понятной всем, кто принимает участие в проекте.

Domain Model должна также определить словарный запас вокруг проекта и  выступать в качестве средства коммуникации для всех участников. The Ubiquitous Language чрезвычайно важное понятие в Domain Driven Design и поэтому оно должно быть получено непосредственно из Domain Model.

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

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

Почему The Domain Model важна?

Итак, Domain это мир бизнеса, Model – решение проблемы, Domain Model – Структурированные знания о проблеме.

Почему это важно для Domain Driven Design? Есть три причины, почему Domain Model имеет важное значение.

Domain Model и сердце дизайна формируют друг друга

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

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

Domain Model является основой языка, используемого всеми членами команды

Каждому человеку в команде проекта следует использовать Ubiquitous Language. Это означает, что у технических и нетехнических людей есть общий язык, чтобы общаться таким образом, нет никакой потери взаимопонимания между сторонами.

Ubiquitous Language должен быть получен непосредственно из Domain Model. Это значит, что без Domain Model  вы не моежете иметь  Ubiquitous Language.

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

The Domain Model is distilled knowledge

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

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

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

Как вы получаете Domain Model?

Получение Domain Model  — это  итеративный подход, который пытается обнаружить реальные проблемы, с которыми сталкиваются и при правильном решении.

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

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

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

Во время этого процесса важные аспекты проблемы должны быть подобраны из языка и дать конкретные определения, чтобы сформировать Ubiquitous Language.

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

Какие есть примеры Domain Model?

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

Тем не менее, в интересах этой статьи, представим, что мы имеем следующую бизнес-проблему, которую  мы должны решить:

  1. Бизнес хочет создать программное обеспечение для управления ИТ-проектами
  2. Проекты являются производными от дорожной карты продукта
  3. Проект определяется по конкретным критериям
  4. Проект передан менеджеру проекта
  5. Менеджер проекта организовывает команду
  6. Планируется

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

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

The Domain Model должна принимать Domain и Model, чтобы сформировать концептуальное решение этой проблемы.

Например, мы можем видеть, что нам, вероятно, понадобятся объекты для дорожной карты, менеджеров проектов, сотрудников, команды и Sprint.

Нам понадобится способ отбора проектов от какого-то персистентного хранения.

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

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

Заключение

Domain Model является важной отправной точкой при выполнении Domain Driven Design проекта.

Domain Driven Design —  это все о решении проблем организации,  Domain Model — это все о понимании и интерпретации важных аспектов данной проблемы.

Domain Model представляет Ubiquitous Language проекта, важные понятия и связи между этими понятиями.

Domain Model следует также использовать как способ подтверждения, что каждый член команды понимает проблему. Domain Model должна фокусировать внимание на конкретной проблеме, и это будет определять лексику и контекст важных вещей, которые должны быть рассмотрены.