[Перевод] Преодоление сложности в самом сердце DDD
Эта статья является переводом материала «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): Реализация домена
Эти шаблоны предоставляют различные способы реализации логики бизнес-домена:
Сценарий транзакции (Transaction Script)
Active Record
Модель предметной области (Domain Model)
Модель домена, основанная на событиях (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, даже если в нем нет единого агрегата.
