Демистификация доменно-ориентированного дизайна

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

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

Вопрос 1: Проблемы с репозиторием

Что вы думаете о репозитории в DDD? Мы должны понять фундаментальную суть, то есть при разработке репозитория в стиле DDD,Обязательно забудьте все детали технической реализации, связанные с доступом к данным.. Интерфейс репозитория относится к доменному слою, и как только мы будем рассматривать репозиторий как объект DAO, мы неожиданно вернемся к старому способу проектирования, управляемого данными.

Эрик пишет в книге: «Репозиторий представляет все объекты типа какколлекция концепций(обычно симулируется)». Это предложение говорит о многом и является источником названия DDD.Управляйте дизайном через домены, то есть в этом процессе проектирования цвет технологии должен быть максимально удален.

Заимствуя метафору Мартина Фаулера для рефакторинга, в процессе проектирования, ориентированного на предметную область, также есть две шляпы: проектирование предметной области и техническая реализация. При разработке предметной области вы должны учитывать логику предметной области, бизнес-правила и модель предметной области, которая должна быть разработана для развития; как только вы начнете сосредотачиваться на технической реализации, вы должны переключиться на технические проблемы, которые совершенно не связаны с предметной областью. Вот что я считаю очень важным:Разделение технической сложности и бизнес-сложности.

Репозиторий — это набор концепций.Во ​​время проектирования предметной области нам необходимо обеспечить целостность концепций предметной области и учитывать ограничения неизменности логики предметной области.Поэтому DDD вводит Aggregate. В то же время DDD ясно соглашается:У агрегата может быть только один репозиторий, который является репозиторием корня агрегата.. Весь доступ к агрегатам должен осуществляться через репозиторий.

Вопрос 2: Как перейти на DDD для проектов, не использующих DDD

В четвертой главе «Дизайн, ориентированный на предметную область», «Разделение доменов» Эрик привел несколько точек применения DDD:

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

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

  • Размер проекта и сложность домена
  • Дизайнерские возможности участников проекта

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

Для этой существующей системы, чтобы перейти от формы без DDD к форме DDD, есть только две стратегии:

  • Стратегия первая:Рефакторинг существующей системы. Обратите внимание, что этот рефакторинг — это не рефакторинг на уровне кода, предложенный Мартином Фаулером, а рефакторинг модели предметной области. Если модели предметной области нет, то нам нужно заново открыть знания предметной области, установить единый язык, а затем извлечь модель предметной области, а затем использовать модель предметной области для управления нашей программой. В настоящее время существующий код необходимо реорганизовать, чтобы он соответствовал знаниям, выраженным моделью предметной области.
  • Стратегия вторая:Если существует четкая граница между функцией существующей системы и новым требованием, то проще рассматривать существующую функцию как ограниченный контекст, затем применять метод проектирования DDD для нового требования и связываться с существующей системой, вводя антикоррозийный слой.

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

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

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

В целом можно рассматривать следующим образом:

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

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

Что касается проектных ограничений микросервисов на хранение данных — «данные каждого микросервиса хранятся отдельно», это относится к уровню инфраструктуры, строго говоря, к предметно-ориентированному проектированию отношения не имеет.

Категории