# Следите за разработчиками Tencent Cloud и отмечайте их

# Еженедельник 3 | Расскажите о моем опыте архитектурного проектирования в Tencent

# Выпуск 7 | Лю Сяонань: Четыре эссе по предметно-ориентированному проектированию – строительство моста между школой Цзянху и академической школой

Фэн Юлань руководит философией и выдвигает методологию «следовать инструкциям» и «продолжать объяснять». За последние два года я периодически разбирал две презентации о предметно-ориентированном дизайне: «Предметно-ориентированный дизайн» и «Четыре эссе по предметно-ориентированному дизайну». Содержание первого в основном представляет собой примечания к чтению классических произведений DDD, которые можно рассматривать как подтверждение того, что человек выучил книгу, а не говорит о Йеху Дзен; второй представляет собой новаторскую интерпретацию, основанную на наследовании; , что можно рассматривать как Чтобы продолжать говорить об этом, люди, которые это сделали, еще не сделали этого. В этой статье основное внимание уделяется «Четырем эссе» и анализируется весь логический контекст DDD с четырех аспектов.

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

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

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

• Школа Цзянху: уделяет особое внимание практике, подчеркивает личное понимание и хорошо разбирается в идеологических системах.
• Академическая школа: уделяет особое внимание нормам и систематическому обучению, хорошо разбирается в методах и системах.

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

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

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

Прошло почти 20 лет с тех пор, как в 2004 году была впервые опубликована книга «Domain-Driven Design·Coping with Software Core Complexity» (английская версия). За это время было написано множество книг, объясняющих DDD, но что именно включает в себя DDD? Казалось, что консенсуса никогда не было, и было ощущение всеобъемлющего характера. В этой статье основное внимание уделяется классическим работам по DDD, относящимся к академическому стилю, и резюмируются DDD в четырех частях:

• структурная теория：тактическое моделированиеистратегическое моделирование。
• Теория процессов: рефакторинг системы и разработка программного обеспечения.
• Язык: на основе смоделированного языка.
• Теория моделирования: Модель, основанная на моделировании предметной области.

Это деление на самом деле отражает мой многолетний практический опыт и теоретическое мышление и не является произвольным. В последние годы жизни Ван Янмин сформулировал то, чему он научился за свою жизнь, в четыре предложения:

• Тело без добра и зла.
• Есть хорошие и плохие поступки.
• Познание добра и зла – это совесть.
• Делать добро и устранять зло — значит проверять вещи.

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

• сложность

«Нет серебряной пули — сущности и случайностей программной инженерии» (No Silver Bullet — Essence and Accidents of Software Engineering), классическая статья по программной инженерии, опубликованная в 1986 году, открыла ящик сложности Пандоры. В статье Брукс сравнил вышедшие из-под контроля сложные программные проекты со средневековым оборотнем, которого можно убить только серебряной пулей. Однако из-за присущей разработке программного обеспечения сложности не существует настоящего «серебряной пули», то есть никакого технического или управленческого прогресса, который мог бы независимо обещать достижение на порядок улучшения производительности, надежности или простоты проектов программных систем внутри страны. десять лет.

Прошли десятилетия, оборотень до сих пор не убит, Человек-Луна по-прежнему миф, где же серебряная пуля?

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

• Способы справиться

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

• DDD исложность

DDD предоставляет некоторые конкретные способы решения проблем:

• Разделение бизнеса сложности и технологии сложности через архитектуру-дизайн.
• Ограниченный контекст используется для разделения большой системы на несколько поддоменов с высокой связностью и низкой связью.
• Знания предметной области абстрагируются с помощью модели предметной области.

• предметно-ориентированное проектирование все еще модельно-ориентированное проектирование ？

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

• Разделение домена и модель домена

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

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

• Дзен дикой лисы о DDD

Я знаком с драйверами домена около 10 лет. Лишь недавно я услышал разговор коллеги о «анемичной модели домена». Затем я проверил это в Интернете и обнаружил, что это был блог, опубликованный Мартином Фаулером в 2003 году. : AnemicDomainModel. Его первоначальная цель — просто указать, что многие люди на самом деле неправильно используют модель предметной области и напрямую приравнивают модель модели предметной области к модели MVC, в результате чего в модели остаются только данные и нет логики, и Фаулер назвал эту ситуацию «анемичная модель предметной области». ".

Фаулер обобщил это неправильное использование как анти-паттерн AnemicDomainModel. В процессе кровообращения некоторые люди переводили «Модель анемического домена» как «модель анемии», а позже вывели «модель застоя», «модель потери крови» и «модель набухания крови». все это поверхностные замечания, не имеющие никакого отношения к Мартину Фаулеру и не имеющие никакого отношения к драйверам домена. Многие блоги понимают DDD на том же уровне, что и MVC/DAO/ORM/TDD, что означает, что они вообще не понимают DDD. Фактически, DDD — это концепция того же уровня, что и MBSE/SysML/UML.

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

• Разделение стратегического моделирования и тактического моделирования.

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

Как следует из названия, стратегическое проектирование – это макропроектирование, то есть моделирование всей системы, которое называется «стратегическим моделированием», тактическое проектирование – это микропроектирование, то есть детальное моделирование частей системы, которое называется «; тактическое моделирование "лепка".

Представленная картина очень ясна:

• стратегическое моделирование

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

Общие методы понимания больших систем:

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

Контекст в DDD — это запутанное слово. В более широкой перспективе Контекст может соответствовать классу UML или блоку SysML, то есть Контекст можно понимать как класс или модуль. ContextMap соответствует взаимосвязи UML/SysML.

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

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

• тактическое моделирование

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

Строительные блоки: спроектируйте систему на уровне класса, объекта, композиции, наследования и т. д. Согласно терминологии DDD, мы можем классифицировать сервисы, события, сущности и объекты значений как атомарные блоки, а библиотеки ресурсов, агрегаты и фабрики — как составные блоки.

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

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

• Обсуждение DDD процесса разработки

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

• Углубление понимания посредством реконструкции
• Гибкий процесс разработки и непрерывная доставка
• Внедрение стандартизированных методов разработки программного обеспечения

• Углубление понимания посредством реконструкции

Основное внимание при проектировании на основе предметной области уделяется этапу проектирования системы, но при проектировании на основе предметной области также важным содержанием является рефакторинг. Третья часть книги «Проектирование, управляемое предметной областью: как справиться со сложностью ядра программного обеспечения» состоит из 6 глав и посвящена рефакторингу. Судя по содержанию, это называется реконструкцией, но на самом деле это все еще проектирование, такое как концептуальное моделирование, гибкое проектирование, режим анализа, режим проектирования и т. д., которые по сути представляют собой некоторый контент проектирования на макроуровне. По содержанию она по-прежнему сильно отличается от книги Мартина Фаулера «Рефакторинг: улучшение дизайна существующего кода».

Когда дело доходит до рефакторинга, никто не может сравниться с книгой Мартина Фаулера «Рефакторинг: улучшение дизайна существующего кода», мастера разработки программного обеспечения.

Основное содержание книги «Рефакторинг: улучшение дизайна существующего кода» можно отобразить в виде интеллект-карты следующим образом.

Со времени выхода этой книги «запах кода» стал стандартным термином в мире разработки. В процессе рефакторинга следует учитывать некоторые основанные на опыте принципы.

Что касается конкретного метода реконструкции, то он может осуществляться с трех сторон: функции, данных и бизнес-логики.

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

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

• Гибкая разработка и непрерывная доставка

В эпоху публикации «Проектирования, управляемого предметной областью» (2004 г.), это была эпоха, когда гибкая разработка и экстремальное программирование становились популярными. Хотя «Проектирование, управляемое предметной областью» не ограничивается фиксированным процессом разработки, оно в основном ориентировано на «гибкий процесс разработки».

Сегодня, двадцать лет спустя, гибкая разработка и экстремальное программирование уже давно пришли в упадок, но книга Учителя Цяо Ляна «Непрерывная доставка» открывает нам новую перспективу. Учитель Цяо Лян разобрался в истории эволюции программного обеспечения в своей книге «Непрерывная доставка». За последние два-три года в качестве внешнего старшего управленческого консультанта Tencent его двухконтурная модель непрерывной поставки 2.0 «исследования стоимости — быстрой проверки» впечатляет.

• Внедрение стандартизированных методов разработки программного обеспечения

Автор последней отечественной книги «Деконструкция предметно-ориентированного проектирования» пытается сослаться на RUP и установить аналогичный нормативный процесс для DDD.

Книга «Деконструкция предметно-ориентированного проектирования» была опубликована в 2021 году. Предполагается, что автор Чжан И является известным экспертом по DDD в отрасли, а также рецензентом книги «Реализация предметно-ориентированного проектирования». В книге «Деконструкция доменно-ориентированного проектирования» автор пытается интегрировать DDD и RUP и предлагает модель DDDUP (унифицированный процесс доменно-ориентированного проектирования). Сможет ли она добиться успеха, мы подождем и посмотрим.

«Деконструкция предметно-ориентированного проектирования» — очень толстая книга, состоящая из более чем 500 страниц. Ее стоит прочитать. Прочитав ее, вы сможете оценить глубокий опыт автора в отрасли.

Унифицированный процесс предметно-ориентированного проектирования (DDDUP) относится к двумерной модели разработки рационального унифицированного процесса (RUP). Как показано на диаграмме двумерной модели всего процесса, горизонтальная ось представляет время продвижения предметно-ориентированного проектирования в процессе строительства, отражая динамическую структуру процесса. Основные элементы состоят из трех этапов, и каждый этап может быть выполнен. состоять из нескольких итераций. Состав; вертикальная ось представляет действия, выполняемые на каждом этапе предметно-ориентированного проектирования, отражая статическую структуру процесса. Составные элементы включают рабочий процесс и метамодель.

• единый язык

ВЕЩЕСТВЕННЫЙ ЯЗЫК, некоторые книги переведены на универсальный язык, а некоторые книги переведены на единый язык. Основные моменты:

• В одной команде один язык, и только когда язык един, можно добиться общения.
• Измените поле Модель на единый языкизCore, общение на основе Модели

• Примеры из сфер бизнеса

В бизнес-доменах есть языки бизнес-доменов, а разные компании используют разные языки. Ниже приведен пример от Tencent Animation.

Примечание. Изображение взято из статьи, написанной внутренним коллегой.

• Примеры из технологических областей

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

В книге «Domain-Driven Design · How to Cope with Core Complexity of Software» четко упоминаются шаблоны проектирования, которые можно рассматривать как язык более высокого уровня, чем языки программирования, и улучшать абстрактный уровень мышления.

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

• Школа Цзянху против академической школы

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

• Модель – это точка подключения

Основная логика DDD, UML и Sysml указывает на модель, а модель является комбинацией трех технологий.

• Ограниченный контекст — ключ к пониманию DDD

Ограниченный контекст — одна из ключевых концепций DDD и, возможно, самая запутанная концепция в DDD. Можно сказать, что если вы понимаете ограниченный контекст, вы поймете DDD. Технически мы можем моделировать ограниченный контекст как объект/класс UML или блок SysML. Как только мы поймем это: ограниченный контекст = объект/класс = блок, все секреты будут раскрыты.

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

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

• UML/SysML — это тяжелое оборудование.

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

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

• строить мосты

Какое-то время я каждый день думал о DDD/UML/SysML, и в моей голове яростно боролись технические системы различных фракций. Я случайно соединил несколько картинок, и вдруг мне пришла в голову идея, и я. в этот момент пришло прозрение. Наконец-то нашел ключ к разблокировке кода. С тех пор несколько основных концепций DDD, которые беспокоили меня долгое время, были наконец прояснены, и последняя часть головоломки всего здания DDD была завершена. Я почувствовал, что наконец-то могу пройти из одного конца дороги в другой. другой конец дороги, а затем с другого конца дороги идите на этот конец дороги. Обратите внимание на таблицу в левом нижнем углу рисунка ниже. Она соответствует основным концепциям между DDD/UML/SysML. Между ними можно установить мост, и с этого момента все можно соединить.

Прошло почти 20 лет с момента основания DDD. За это время DDD сильно разросся и постепенно превратился в хаотичные технические джунгли. В ста книгах есть сто способов объяснить все. Однако профессиональные методы, такие как UML/SysML/RUP, также имеющие долгую историю, постепенно приходят в упадок.

Почему DDD так приятно пахнет? В чем секрет? Что касается самого DDD, то это в лучшем случае идеологическая система, и она далека от развития в стандартизированный метод. Он имеет большое пространство для интерпретации и много возможностей для игры. Это очень удобно с технической точки зрения. консалтинговой индустрии, чтобы использовать его для упаковки и рассказывания историй. Соответственно, профессиональные методы, такие как UML/SysML/RUP, имеют меньше возможностей для развития из-за своей строгости. Самое главное, что UML/SysML/RUP защищены авторским правом, и каждая из них запустила собственную систему профессиональной сертификации. Это мешает многим. технологические консалтинговые компании от входа.

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

У меня академическое образование, и я лучше знаком с методами академической школы. Однако школа Цзянху очень популярна, прежде чем я познакомился с ней и начал ее углубленное исследование. Я кое-что получил, я понял одну вещь с точки зрения методологии: использовать систему знаний академической школы в качестве основы, используя метод фракции Цзянху для рассказывания историй, только объединив две фракции, можно достичь превосходных боевых искусств. Это чем-то похоже на сочетание китайской и западной медицины. Западная медицина используется в качестве основы, а китайская медицина используется для путешествий по миру. Даже если это не увенчается успехом, это недалеко. Один великий человек однажды сказал, что он ценит Ци «предпочитает смелость и элегантность», а мое отношение к различным техническим школам – «предпочитаю академизм и не отказываюсь от мира».

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

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

-End-

Автор оригинала｜Лю Сяонань

📢 Как вы понимаете доменно-ориентированный дизайн? Есть ли у вас какие-либо рекомендации по хорошим методам обучения? Добро пожаловать, чтобы оставить сообщение.