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

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

Дизайн, управляемый доменом (DDD)

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

Давайте рассмотрим несколько терминов.

Домен

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

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

Контекст

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

Модель

Строительные блоки домена. Различные части, которые объединяются для решения проблемы. В нашем случае нашими моделями становятся люди в их различных ролях, ингредиенты, пицца, мебель, машины и т. д.

Повсеместный язык

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

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

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

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

Принципы DDD

Моделируйте программное обеспечение в соответствии с бизнес-сферой

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

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

Программное обеспечение развивается в ограниченном контексте

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

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

Один поддомен не нарушает работу другого.

Создавайте домены, отдавая предпочтение мнению экспертов в этой области

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

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

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

Преимущества DDD

Давайте посмотрим на преимущества дизайна, ориентированного на предметную область.

  1. Более простое общение, потому что все разговоры ведут эксперты в предметной области.
  2. Гибкость — каждый компонент может развиваться независимо
  3. Уменьшение непонимания — благодаря использованию последовательного языка и терминов.
  4. Улучшенная координация команды — благодаря суженным сферам деятельности
  5. Более чистая архитектура — потому что разделение ответственности снижает риск раздувания программных компонентов.

Когда не следует практиковать DDD?

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

  1. Ожидается, что программное обеспечение не будет быстро расти
  2. Первоначальная стоимость должна быть низкой
  3. Когда время доставки является проблемой

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

Подробнее обо мне можно узнать здесь

Первоначально опубликовано на https://dev.to 10 октября 2021 г.