Что такое доменная модель
Перейти к содержимому

Что такое доменная модель

  • автор:

Ценности DDD

Основоположником DDD (Domain Driven Design, предметно-ориентированное проектирование) является Эрик Эванс, который в довольно далеком 2003 году подарил миру свою знаменитую книгу о предметно-ориентированном проектировании. Безусловно, не все, что описано в книге придумал автор с нуля. Многие идеи и практики существовали и до него, но у Эванса получилось все это систематизировать и правильно расставить акцента. Давайте попробуем разобраться, что же именно предлагает Эванс.

На мой субъективный взгляд DDD стоит на трех основных столпах (и это если что не три буквы Д):

  • Доменная модель
  • Ограниченный контекст
  • Агрегаты

Доменная модель

Transaction Script и Domain Model

Данное понятие существовало и до Эванса. Например, Мартин Фаулер ставит доменную модель в противоположность так называемому подходу Transaction Script, который представляет своего рода более процедурный стиль кодирования, чем объектно-ориентированный. Обычно при таком подходе акцент смещается в сторону базы данных и манипуляций с данными, чем в сторону работы с бизнес-логикой. Обычно такой подход реализуется как некая сущность, отображаемая на базу данный, с большим количеством геттеров и сеттеров. И управляющей класс, некий сервис, который и вызывает эти сеттеры и по определенным правилам обновляет базу данных. Доменный слой, построенный на основе подобных сущностей, Фаулер также называет анти паттерном — анемичная модель. Фаулер обосновывает это тем, что в настоящем объекте должны быть не только данные, но и поведение.

If all your logic is in services, you’ve robbed yourself blind.

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

В отличие от Transaction Script, где логика содержится в сервисах, а данные в сущностях, в доменной модели и логика и данные размещены в доменных объектах. Согласно идеям объектного-программирования такие объекты инкапсулируют свое внутреннее состояние, а для работы с ним предоставляют вполне определенный внешний интерфейс. Например, у объекта корзины может быть метод добавления товара. Тут можно возразить и сказать, что у нашей сущности вполне может быть сеттер для добавления товара.

Да, все это верно. Но не стоит забывать, что в идеале класс корзины должен соблюдать ряд бизнес-инвариантов. Например, после добавления товара в корзину, итоговая стоимость корзины должна увеличится на сумму добавленных товаров. В подходе Transaction Script данная логика размещается в сервисе. Но при таком раскладе соблюдение инвариантов не обеспечивается ничем, кроме хороших тестов и внимательности программиста. Существует не нулевая вероятность, что в каком-то другом сервисе проявится ошибка и он изменит данные корзины неверным образом. В случае же с доменной моделью, за корректность изменения данных (за соблюдение инвариантов) отвечает только один объект сама корзина (может быть еще ее «внутренние классы», но опять же об этом мы не знаем, за счет соблюдения подхода сокрытия информации). Таким образом мы формируем абстракцию корзины, с которой должны взаимодействовать другие классы модели, через ее определенный интерфейс, а не влияя напрямую на ее внутреннее состояние. Также автоматически начинают соблюдаться еще и такие принципы, как SRP (принцип единственной ответственности), low coupling и high cohesion (слабая внешняя связанность и высокое внутреннее зацепление).

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

Единый язык

Единый язык — это некий набор терминов, относящихся к разрабатываемой доменной модели, который использует команда разработки в общение между собой. Важно заметить, что в состав команды входят не только разработчики, но и бизнес-эксперты. Единый язык — это не язык программистов, так же это и не язык бизнес-аналитиков. Единый язык — это своего рода некое смешение, которое возникает в результате совместной работы этих двух категорий специалистов. Это позволяет, как программистам при общении с доменными экспертами более погрузиться в предметную область, так и специалистам предметной области понять, что же все же пытаются создать разработчики (Безусловно, доменные эксперты должны иметь поверхностное представление об объектно-ориентированном моделировании, они не должны впадать в ступор только лишь при упоминании таких слов, как класс и объект). При этом доменные эксперты могут дать обратную связь разработчикам даже до момента написания первой строчки кода. Во время анализа способов использования системы (use cases) разрабатываемой системы, обсуждение, которых должно вестись с активным применением терминов из словаря Единого языка.

DDD — это про общение между людьми, одна из его задач — сломать имеющийся «языковой барьер» между бизнесом и разработкой.

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

Размышляя на тему DDD и хорошо проработанной доменной модели у меня всегда возникает ассоциация с небезызвестным высказыванием:

Сначала ты работаешь на репутацию, а потом она работает на тебя.

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

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

Тут уже все несколько посложнее. Есть понятие предметная область, она же и есть домен (domain). Это та сфера деятельности, в которой работает наш бизнес. Например, тот же самый e-commerce, доставка еды из ресторанов, бухгалтерская сфера или что-то иное. В любом случае это весьма обширная сфера и при разработке ПО нет смысла моделировать всю эту огромную область.

Практически всегда в нашей предметной области есть подобласти (subdomain). Подобласти это своего рода отдельно взятые «боли» бизнеса, т.е. это бизнес-проблема, бизнес-задача, которую требуется решить в нашем случае за счет автоматизации. Например, нам может требоваться автоматизация для формирования заказов, для производства товаров, для их доставки. Все это разные подзадачи из одной и той же предметной области. Можно переформулировать иначе. На предприятии могут быть разные подразделения: производство, доставка и служба продаж принимающая заказы и наша цель состоит в разработке ПО для данных подразделений предприятия.

Разное использование понятий в зависимости от контекста

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

Например, заказ для отдела продаж содержит информацию о покупателе, набор заказанных товаров. Он может предоставлять такие методы, как изменение статуса или выполнение возврата. Для службы доставки столь подробная информация не требуется, курьеру понадобится знать вес и габариты заказа, но вовсе не обязательно знать, что внутри. В свою очередь, если заказ передается на производство, то там не требуется информация о клиенте и о ценах. Для производства важно, то что требуется сделать, т.е. только сами товарные позиции. Также у понятия заказа в разных подразделениях может быть абсолютно различный жизненный цикл. Понятие заказ для разных подразделений отличается не только разными данными, но и различным поведением. Мы видим, что казалось бы одно и то же понятие может использоваться по-разному. Можно прийти к выводу, что такие понятия должны и моделироваться по-разному. В виде различных классов, размещенных в различных моделях.
Также если продолжить анализ задач наших подразделений, то непременно всплывут и такие понятия, которые никак не пересекаются и не накладываются друг на друга. Например, в службе приема заказов, может появиться понятие корзины покупателя, которое отсутствует как в производстве так и в доставке. В службе производства вполне может быть понятие материала или некого ресурса. А в службе доставки может существовать такое понятие как интервал доставки, которого также нет ни в одном из других подразделений.

Давайте зайдем с другой стороны. К нам пришел клиент, мы начинаем анализировать предметную область, накидываем черновые диаграммы классов и диаграммы взаимодействий. И на этом этапе уже вполне может быть возможно увидеть потенциальные границы субдоменов.
При этом некоторые классы, например, тот же заказ оказывается на проведенной границе. Такие пограничные классы мы можем рассмотреть с позиций их функций в контексте подобластей, к которым они относятся. В ходе анализа может выясниться, что для одной подобласти эти классы выполняю одну роль, а для другой другую. Это опять же наталкивает на мысль, что подобные понятия следует моделировать по-разному. Когда данные пересекают границу подобластей, должно происходить отображение одного граничного объекта на другой, из второй подобласти.

Области задач и области решений

Вон Вернон рассматривает субдомены, как области бизнес-задач, а ограниченные контексты, как области решений.

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

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

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

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

Ограниченный контекст как способ декомпозиции системы

Идея ограниченного контекста это своего рода желание декомпозировать большую систему на более простые компоненты, с которыми понятней и более удобно работать. Также можно сказать, что данная идея реализует все те же принципы проектирования SRP, low coupling и high cohesion, но только на более высоком уровне. Об этом также говорит принцип CCP (Common Closure Principle), который похож на SRP, но только для классов, изменяющимся по одной и той же причине и следовательно должны находится вместе, например, в одном пакете. Также эта идея отлично согласуется с другими подходами, например, с микро сервисной архитектурой и с гибкими командами в Agile.

Закон Конвея

Говоря о декомпозиции систем вспоминается закон Конвея.

Организации проектируют системы, которые копируют структуру коммуникаций в этой организации

Даже когда я приводил пример с подразделениями организации, то невольно рассматривалась декомпозиция системы по бизнес-возможностям предприятия, которые уже структурированы определенным образом. Что на мой взгляд перекликается с законом Конвея.

Декомпозицию на основе объектно-ориентированного анализа можно рассматривать как альтернативный подход, который более точно моделирует исследуемую предметную область. Такое моделирование может даже выявить неэффективную (слишком запутанную, с сильным связыванием) структуру подразделений в нашем бизнесе.

Например, Обратный маневр Конвея рекомендует развивать команду и структуру организации для продвижения желаемой архитектуры.

Агрегаты

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

Приходилось ли вам в коде видеть что-то подобное?

payment.GetOrder().getAccount().getClient().getAddress() 

Данный код представляет своего рода довольно глубокий обход графа объектов нашей предметной модели. В нашей модели имеются несколько объектов-сущностей: Payment, Order, Account, Client И Address. И все эти объекты имеют некоторые связи друг с другом. B это довольно знакомая и распространенная ситуация. И само собой такая тесная связь между объектами вызывает и большую связанность самого кода. И это даже не говоря о том, что такая связь может быть не всегда обязательной и тем самым, подобный невнимательный обход объектов может вызывать исключение NullPointerException.

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

Агрегат как граница транзакционной согласованности

Когда говорят про агрегаты не редко упоминают транзакционную согласованность этих агрегированных объектов. Например, в качестве агрегата, можно рассмотреть корзину товаров. Корзина помимо своих основных свойств таких, как подытог, скидка и итоговая сумма содержит такие объекты как CartItem. Данный объект представляет элемент корзины и может содержать такие свойства, как добавленный товар и его количество, а также может вычислять подытог, как произведение количества на стоимость товара. Агрегат корзина (как и любой доменный объект) обеспечивает необходимые бизнес-инварианты (например, пересчет стоимости при добавление еще одного товара). Также очевидно, что при сохранении корзины должны одновременно сохраняться и ее элементы в рамках одной транзакции, что удовлетворяет транзакционной согласованности.

По этому при проектировании агрегата всегда можно задаться вопросом:

А должны ли эти объекты сохраняться вместе?

Агрегаты и границы ограниченных контекстов

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

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

Агрегаты и событийно-ориентированный архитектура

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

Заключение

В статье были рассмотрены на мой субъективный взгляд самые интересные подходы используемые в DDD. Несмотря на то, что Эванс представил свою книгу чуть ли не двадцать лет назад, до России все доходит и небольшим опозданием. И даже 20 лет спустя в нас DDD до сих пор имеет некую таинственность и массу непонимания. Надеюсь, что данная статья сможет внести свой небольшой вклад и прояснить некоторые моменты.

  • DDD
  • проектирование систем
  • доменная модель
  • архитектура приложений
  • Программирование
  • Анализ и проектирование систем
  • Проектирование и рефакторинг

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

Если вы следили за 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 должна фокусировать внимание на конкретной проблеме, и это будет определять лексику и контекст важных вещей, которые должны быть рассмотрены.

5.1.3 Доменная модель приложения

Доменная модель (domain model) — это не что иное как модель предметной области приложения. В рамках даже такого относительно небольшого приложения, эта модель довольно объемна. На рис. 7 представлена ее диаграмма классов.

Рис.7. Диаграмма классов приложения “Тестер”

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

Наибольший интерес в дальнейшем будут представлять классы пользователя (User) и теста (Test):

public class User implements Serializable

String login, password, name, surname, patronymic;

public class Test implements Serializable

String name, description, notes;

Большая часть кода в этих листингах опущена для краткости.

Domain driven design

Domain driven design (DDD) — подход к разработке приложений, основанный на выделении доменов (domain). Домен — область знаний/деятельности, для которой разрабатывается приложение. Ясно, что для юристов есть свои термины и важные понятия, которые отличаются от слов, используемых в нефтегазовой промышленности. Причем это не просто слова, они отражают важные для заказчика процессы, связи. Именно поэтому важно уделять внимание терминам, которые используются в данной сфере. Это обеспечивается постоянным общением двух сторон — разработчиков приложения и клиентов. Такой подход отражает главный принцип DDD — разработка не должна быть в отрыве от бизнес-задач. DDD не является инструкцией или методологией, а составляет набор правил и ориентиров.

ESM-платформа SimpleOne

Для небольших и несложных программных продуктов DDD, как и другие принципы проектирования архитектуры, не так важны. Но узкие предметные области, обладающие сложной спецификой, требуют тщательного продумывания на самом высоком уровне. DDD предлагает создавать модели предметных областей, содержащие сложную бизнес-логику. Модель — система абстракций, которая описывает отдельные характеристики домена. Как и физическая модель, упрощающая понимание и изучение объекта, помогает решить проблемы, связанные с данным доменом. Агрегаты представляют собой объединения сущностей и ценностных объектов с четко очерченными границами. Можно представить себе агрегат просто как группу, которая позволяет обращаться сразу ко всем элементам, входящим в неё. Например, вместо того чтобы делать команду «нарезать яблоко» и повторять её n раз, можно все яблоки объединить в группу «яблоки» и применить к этой группе команду «нарезать». Сервисы — это функции, которые не привязаны к сущностям или ценностным объектам. Грубо говоря, действие в себе. Репозитории — это такие сервисы, которые используют глобальный интерфейс, чтобы обеспечить доступ ко всем сущностям и ценностным объектам, находящимся в конкретной группе агрегатов. Например, можно считать команду «резать» репозиторием, когда она применяется к группе агрегатов «фрукты», которая включает агрегаты «яблоки», «груши», «бананы». Использование подхода «Domain driven design» при проектировании архитектуры сложных корпоративных информационных систем позволяет сделать проще поддержание изменений в проекте и эффективнее тестировать новые релизы.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *