Для установки нажмите кнопочку Установить расширение. И это всё.

Исходный код расширения WIKI 2 регулярно проверяется специалистами Mozilla Foundation, Google и Apple. Вы также можете это сделать в любой момент.

4,5
Келли Слэйтон
Мои поздравления с отличным проектом... что за великолепная идея!
Александр Григорьевский
Я использую WIKI 2 каждый день
и почти забыл как выглядит оригинальная Википедия.
Статистика
На русском, статей
Улучшено за 24 ч.
Добавлено за 24 ч.
Что мы делаем. Каждая страница проходит через несколько сотен совершенствующих техник. Совершенно та же Википедия. Только лучше.
.
Лео
Ньютон
Яркие
Мягкие

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

Из Википедии — свободной энциклопедии

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

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

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

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

Данный термин был впервые введен Э. Эвансом в его книге с таким же названием «Domain-Driven Design»[1].

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

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

Концепция

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

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

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

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

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

Целостность

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

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

Взаимосвязь

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

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

Элементы DDD

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

Ограниченный контекст

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

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

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

Сущность

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

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

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

Агрегат

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

Службы предметных областей

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

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

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

Примечания

  1. Evans, Eric  (англ.). Domain-Driven Design: Tackling Complexity in the Heart of Software (англ.). — Addison-Wesley, 2004. — ISBN 978-032-112521-7. в русском переводе Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем
  2. Brian Foote and Joseph Yoder, Big Ball of Mud Архивная копия от 27 мая 2012 на Wayback Machine, 1999, Urbana, IL 61801 USA
  3. Haywood, D., Domain-Driven Design using Naked Objects Архивная копия от 9 сентября 2017 на Wayback Machine, 2009, Pragmatic Programmers

См. также

Литература

  • Вон Вернон. Реализация методов предметно-ориентированного проектирования = Implementing Domain: Driven Design. — М.: «Вильямс», 2016. — 688 с. — ISBN 978-0-321-83457-7.
  • Эрик Эванс. Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем = Domain-Driven Design: Tackling Complexity in the Heart of Software. — М.: «Вильямс», 2011. — 448 с. — ISBN 978-5-8459-1597-9.
  • Нильссон Д. Применение 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.

Ссылки

Видео
Эта страница в последний раз была отредактирована 20 мая 2022 в 09:04.
Как только страница обновилась в Википедии она обновляется в Вики 2.
Обычно почти сразу, изредка в течении часа.
Основа этой страницы находится в Википедии. Текст доступен по лицензии CC BY-SA 3.0 Unported License. Нетекстовые медиаданные доступны под собственными лицензиями. Wikipedia® — зарегистрированный товарный знак организации Wikimedia Foundation, Inc. WIKI 2 является независимой компанией и не аффилирована с Фондом Викимедиа (Wikimedia Foundation).