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

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

01. Концепция доменного управления

Концепция доменного привода была впервые предложена мастером Эриком Эвансом в его знаменитой книге «Доменно-ориентированный дизайн: решение проблемы сложности в сердце программного обеспечения», опубликованной в 2003 году. Из названия мы можем интуитивно понять, что DDD призван решить проблему сложности. Проблема программных систем — это методология уменьшения сложности бизнес-систем. Многие студенты думают, что драйвер предметной области труден для понимания, поскольку он предлагает множество абстрактных концепций. Мы могли бы сначала отбросить эти концепции и понять, как он решает проблемы.

1.1 Унификация языка и модели

Для развития,В одном предложении наша работа: использовать код для реализации требований.,В процессе реализации разные люди и разные команды,Могут быть разные практики,Доменный привод — один из путей реализации. Доменно-ориентированные попытки построить мост между требованиями и кодом,название мостаЭто называется единым языком и моделью.

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

Так что же такое Модель Шерстяная ткань？Я резюмирую это как：Абстракция, которая упрощает сложное,Цель абстракции — упростить задачи.,Сначала игнорируйте детали и думайте о проблеме с верхнего уровня.Абстракция не зависит от формы выражения, а зависит от того, как смотреть на проблему и анализировать проблему. Для иллюстрации приведем несколько примеров:

• Сколько шагов нужно, чтобы поместить слона в холодильник? Всего три шага,открыть холодильник->Посади в слона->закрыть холодильник。

Хотя это шутка,Но я должен сказать,Это хороший вариантПроцессно-ориентированная абстракция.

• Программа = структура данных + алгоритм.

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

• Диаграммы классов, блок-схемы, диаграммы архитектуры...

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

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

1.2 Разделяй и властвуй: еще один разговор о сортировке слиянием

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

Кратко рассмотрим идею сортировки слиянием:

1. Уточнить функцию, ввод и вывод основной функции;
2. Декомпозировать задачу и определить функции, входы и выходы декомпозированных подфункций;
3. Для объединения результатов подфункций псевдокод выглядит следующим образом:

//Основная функция
void mergeSort(std::vector<int>& arr, int left, int right) {
   int mid = left + (right - left) / 2;

    //Разделить процесс Один разделился на двоих
    mergeSort(arr, left, mid); //Подфункция 1 
    mergeSort(arr, mid + 1, вправо);//Подфункция 2

    //Объединяем процесс 
    merge(arr, left, mid, right);

}
//Функция слияния
void merge(std::vector<int>& arr, int left, int mid, int right) {
    //выполнить
}

и Драйвер домена до сих пор использует эту идею в процессе реализации, то есть：Определите проблему, разбейте ее и объедините результаты.

Проблема определения:Когда мы сталкиваемся со сложной сценой,Для начала необходимо определить, с какой проблемой вы столкнулись? Где границы проблемы (ограниченный контекст)?,Легко понять ценность решения проблемы, но легко упустить из виду ценность ее определения.В проектной практике,Не знаю, сталкивались ли вы когда-нибудь с таким сценарием: технические одноклассники сразу попадут в техническую реализацию на основе описания одноклассников продукта.,Только во время процесса принятия он скажет: «Ой.,Получается, что нужно только осознать эту потребность».,Здесь основная проблема не обнаруживается.

Разберём проблему:Определение проблемы четко проясняет границы проблемы.,Мы можем разделить проблему в границах,Основная идея доменно-ориентированного подхода заключается вразделяй и властвуй,То есть разделение подзадач с «четкими границами».,Затем решите подзадачи. Вот как решить проблему,Явамикросервисы Идеи разделения имеют разные подходы, но одну и ту же цель.（говоря омикросервисы Здесь поднимаются два интересных вопроса Во-первых: драйвер домена — это концепция, предложенная в 2003 году, почему она постепенно не стала известна всем примерно 15 лет назад, во-вторых: какова связь между микросервисами и драйвером домена, я полагаю, что после прочтения этой статьи вы? почувствую Есть ответы)

Объединение результатов: решения подзадач одну за другой недостаточно,Как связать информацию воедино — сложная часть,Проблемы с соединением могут возникнуть в процессе натягивания струн.,Это возвращает нас к распространенной проблеме в практике разработки программного обеспечения.：как это сделать«Высокая связность, низкая связанность»,На самом деле, осторожные друзья уже обнаружили,Цель проблемы декомпозиции здесь соответствует высокой связности.,Целью объединения результатов является низкая связанность.

02. Эти непонятные термины

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

2.1 Работа в границах: домены и поддомены

Концептуально поле означает: сферу участия в специализированной деятельности или карьере.,Ключевым моментом здесь является область действия слова.,Область действия — это граница. Независимо от того, какую проблему мы решаем,Проблемы всегда имеют границы,Чем четче границы,Чем яснее будут идеи решения проблем.,Проще говоря,Домен — это проблема, которую необходимо решить в пределах границы.для сложной проблемы,Используйте разделение и Идею властвуй можно разделить на подпроблемы. Такая идея исследования проблем на самом деле является обычным явлением. Если нам нужно изучить человеческое тело, то при изучении человека мы можем разделить проблему на подзадачи в соответствии с различными методами. Ниже приведены две. разные идеи. Изображение слева основано на «системе». Разделение: изображение справа разделено по «композиции».

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

Когда процесс разложения завершен,Мы решаем подзадачу,Затем ищите соответствующие решения,Этот процесс идет от области проблемы к области решения.Следующее изображение может помочь вам понять более непосредственно。

2.2 Домены подразделяются по функциям: основной домен, общий домен, вспомогательный домен.

В процессе непрерывного деления,Субдомены также могут быть реорганизованы по различным функциям в: основной домен, общая зона, домен поддержки.,Здесь необходимо подчеркнуть, что разделение поддоменов полностью основано на понимании бизнеса.,Основано на бизнесе, а не на технологиях.

• основной домен

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

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

• общая зона

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

• поддержка домена

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

2.3 Сущности и объекты значений

что такое сущность？Есть в бизнесеОбъект с уникальным идентификатором.Например, в сценарии электронной коммерции,Объект элемента может быть сущностью,Предметыуникальный идентификаторсимвол（вещь id), деловая эффективность товара может измениться, но идентификатор остается неизменным на протяжении всего бизнес-цикла. Например, товар является товаром до покупки и становится товаром, подлежащим отправке после покупки. Если требуется возврат средств, он становится. предмет, который необходимо отозвать, но идентификатор предмета не изменится.

Каково значение объекта? Нацельтесь на объект сущности,Только одинуникальный идентификатора недостаточно,Недостаточно описать характеристики объекта.,Итак, есть атрибуты,Например, атрибуты продукта обычно включают название, цену, изображение, место производства.,иОбъект значения — это набор атрибутов бизнес-сущности.

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

//сущность 
//класс элемента
public class Product{
    private String productId; //Уникальный первичный ключ уникальный идентификатор 
    private String productName;     
    private String productUrl; 
    private String productPrice; 
    Private Address  productAddress；// Коллекция недвижимости
    // get set деловое поведение ...
    public function（）{}
}
//ценитьобъект 
//класс адреса склада (без идентификатора первичного ключа)
public class ProductAddress{
   private String Province；
   private String City；
   private String District；
}

2.4 Агрегация и корень агрегата

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

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

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

03. Разделить и объединить

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

3.1 Сплит и микросервисная архитектура

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

void mergeSort(std::vector<int>& arr, int left, int right) {
    //Разделить процесс
    //помещаем mergeSort(arr, left, середине) переписывается как 
    int resA=rpc.funtionA();    
    //помещаем mergeSort(arr, mid + 1, справа) переписывается как 
    int resB=rpc.funtionB();    

    //Объединяем процесс merge(arr, left, mid, правильно) изменилось на
    func(resA,resB);   
}

Подумайте, разве это не тот код прикладного уровня, который мы обычно пишем? Сначала удаленно и синхронно вызываем службу A для получения информации, затем синхронно вызываем службу B, а затем объединяем все данные результата для расчета и возврата, как показано на рисунке. рисунок ниже.

Разве это немикросервисы Многоуровневая архитектура！Последней формой реализации доменно-ориентированного подхода являются микросервисы.На этом этапе вы можете ответить на один из вопросов, заданных выше.,Почему концепция предметной области была предложена в 2002 году?,Но об этом стало известно только спустя 15 лет.,Это потому, что развитие облачной и микросервисной архитектуры началось около 15 лет назад.,Это обеспечивает почву для выживания концепций, ориентированных на предметную область; напротив, управляемая предметная область также обеспечивает необходимую методологию для проектирования микросервисов;

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

3.2 Лучшие практики слияния: события предметной области

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

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

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

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

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

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

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

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

04. Резюме

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

-End-

Оригинальный автор | Лу Хаомао