Эта статья является переводом материала «Tackling Complexity in the Heart of DDD».

Давайте проведем небольшой эксперимент: попробуем объяснить суть предметно-ориентированного проектирования (DDD) тому, кто понятия об этом не имеет. Это, особенно если делать кратко, непросто. Ограниченные контексты, сущности, события домена, объекты значений, домены, агрегаты, репозитории… с чего начать?

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

Давайте начнем с определения смыслового ядра: в чем заключается основное конкурентное преимущество DDD и каковы средства его достижения?

Смысловое ядро (core domain): Единый язык (Ubiquitous Language)

В «Domain-Driven Design: Tackling Complexity in the Heart of Software» (Синяя книга) Эрик Эванс утверждает, что плохое сотрудничество между экспертами в предметной области и командами разработчиков программного обеспечения приводит к провалу многих попыток разработки. DDD стремится повысить показатели успеха за счет преодоления этого разрыва в сотрудничестве и коммуникации.

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

Единый язык следует широко использовать на протяжении всего проекта. Все общение должно происходить на этом языке. В нем должна быть оформлена вся документация. Даже код должен «говорить» на едином языке.

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

Определение единого языка - это не тривиальная задача. Поскольку программное обеспечение плохо справляется с неоднозначностью, каждый термин единого языка должен иметь ровно одно значение. К сожалению, человеческие языки работают не так — часто слова имеют разное значение в разных контекстах. Чтобы преодолеть это препятствие и поддержать процесс развития строгого языка, используется другой шаблон DDD: ограниченный контекст (Bounded Context).

Служебная подобласть (Supporting Sub-Domain): ограниченные контексты

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

Хотя шаблон «ограниченный контекст» является неотъемлемой частью DDD, я считаю его служебной подобластью, поскольку его цель - поддерживать формирование единого языка, смыслового ядра.

Как я упоминал ранее, код также должен «говорить» на едином языке ограниченного контекста, в котором он реализован. Но как реализовать бизнес-домен в коде? Не существует универсального шаблона для реализации бизнес-домена. Доступно несколько вариантов, и это наша следующая остановка. Имейте в виду: священные коровы вот-вот пострадают…

Неспециализированная подобласть (Generic Sub-Domain): Реализация домена

Эти шаблоны предоставляют различные способы реализации логики бизнес-домена:

  1. Сценарий транзакции (Transaction Script)

  2. Active Record

  3. Модель предметной области (Domain Model)

  4. Модель домена, основанная на событиях (Event-Sourced Domain Model)

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

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

Поскольку методология DDD не может охватывать все шаблоны реализации бизнес-домена, это ноу-хау может и нужно заимствовать из других источников. Например, сценарий транзакции, Active Record и даже Domain Model описаны в книге Мартина Фаулера «Patterns of Enterprise Application Architecture». По определению, способность полагаться на «готовые» решения делает их неспециализированными подобластями. Да, даже шаблон Domain Model.

Последствия

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

Первое последствие – снижение сложности

Эта карта Эрика Эванса изображает шаблоны, составляющие DDD:

А вот как это будет выглядеть, если отбросить шаблоны тактического моделирования:

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

Отделение DDD от шаблонов тактического моделирования предотвратит многие заблуждения и трудности, с которыми сталкиваются многие новички – например, чтение первых четырех глав «Синей книги» и ощущение, что они хорошо разбираются в DDD. И, говоря о «Синей книге», многие жалуются, что в ней недостаточно примеров кода. Ну, угадайте что? Как только DDD будет отделен от шаблонов тактического моделирования, больше не требуется никаких примеров кода вообще. Это чистая методология системного моделирования, которая может быть применена в любом технологическом стеке и любой парадигме программного обеспечения.

Второе последствие – расширение применимости

Я категорически не согласен с мнением о том, что DDD следует применять только к сложным проектам. Это понятие вызвано сильной связью DDD с шаблоном модели предметной области (Domain Model). Как только мы разорвем эту связь, откроется целый новый мир возможностей.

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

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

Микросервисы

Микросервисы в наши дни очень популярны. Расширение применимости DDD к большему количеству типов проектов позволит многим решениям на основе микросервисов использовать бесценные инструменты DDD. Шаблон ограниченного контекста предоставляет бизнес-ориентированный способ разделения системы на набор независимых сервисов, а структурная карта (Structure Map) - отличный способ сопоставить топологию сервисов и шаблоны взаимодействия между ними. (стоит прочесть статью «Bounded Contexts are NOT Microservices» Владислава Кононова, в которой он переосмыслил связь между шаблоном Bounded Context и микросервисами)

"Ты свихнулся?"

Это то, о чем вы, вероятно, думаете прямо сейчас. Однако я не думаю, что мое предложение – убрать тактические шаблоны из DDD – такое безумное, как кажется на первый взгляд. Еще на конференции DDD Europe 2016 сам Эрик Эванс заявил, что реализация Domain Model, описанная в «Синей книге», была задумана как способ реализации модели домена, но многие ошибочно приняли ее за способ реализации DDD. Видите ли, тактические шаблоны моделирования никогда не предназначались для того, чтобы быть единственным и неповторимым способом выполнения DDD, но многие считают их таковыми.

Кроме того, вы не можете сказать, что DDD находится в идеальном состоянии и не имеет причин для изменений. К сожалению, низкие показатели его внедрения говорят сами за себя. DDD заслуживает гораздо большего внимания, чем получает. Синяя книга вышла в далеком 2003 году, и с тех пор методология почти не изменилась. Я считаю, что это должно измениться. Не потому, что это плохо – наоборот, потому что это здорово. У DDD гораздо, гораздо больший потенциал.

Заключительные мысли

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

Комментарии (7)


  1. HellWalk
    07.11.2021 15:04
    +2

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

    Во первых, почему не могу?

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

    Уж авто-тесты то далеко не везде есть, что уж говорить о DDD.

    Ограниченные контексты, сущности, события домена, объекты значений, домены, агрегаты, репозитории… с чего начать?

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

    А это:

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

    Ни о чем. Регулярные споры о DDD в телеграм-каналах показывают, что у каждого свое понятие об удобном и понятном. Если в компании выделяется время на ревью кода, если никто не встает в позу «я умный, а вы ничего не шарите» - то уже хорошо.

    Ну и не забываем про «лучшее враг хорошего»


  1. sky2high0
    08.11.2021 14:05
    +2

    Спасибо за статью, стимулирующую дальнейшие размышления.

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

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

    Есть ли какой-то емкий гайд, туториал, что угодно про DDD с конкретным примером?


    1. ArkadiyXIII Автор
      08.11.2021 16:24
      +1

      Сам еще эту книгу не успел прочесть, но по отзывам других она крутая. Автор тот же, что и у оригинала статьи — Влад Кононов. www.amazon.com/Learning-Domain-Driven-Design-Aligning-Architecture/dp/1098100131


    1. padla_ming
      09.11.2021 08:43
      +1

      Есть бесплатная книжка с примерами, по ощущениям много про DDD


      1. sky2high0
        09.11.2021 15:44
        +1

        Спасибо Падла и Аркадий. Посмотрю. Хорошо бы, правда, суть вещей в статьях раскрывать, а не кидаться книжками )


        1. funca
          10.11.2021 00:13
          +1

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

          Предложение по сути сводится к тому, чтобы убрать из повествования всех этих пугающе объемных книжек ненужные частности и примеры (tactical patterns), оставив лишь максимально абстрактные вещи, специфичные для DDD как философии проектирования программного обеспечения.

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

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


    1. zhainar
      23.11.2021 18:04

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