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

01

Предисловие

В ходе формирования команды по гибкому подходу в этом году я внедрил автоматическое модульное тестирование в один клик с помощью Suite executor. Кроме экзекьютора Suite, какие еще экзекьюторы есть у Juint? Здесь начинается мое путешествие по исследованию Раннера!

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

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

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

Здесь мы возьмем бизнес среднего офиса в качестве примера для практики и применения.

Дружеское напоминание: посмотрите каталог и загляните внутрь целиком.

02

статус-кво

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

2.1 Проблемы, с которыми сталкиваются при разработке программного обеспечения

• Неопределенность в разработке программного обеспечения присутствует на протяжении всего жизненного цикла разработки программного обеспечения.
• В разработке программного обеспечения не может быть «серебряной пули» для решения проблем сложности программного обеспечения.
• Основная суть разработки программного обеспечения — социальная инженерия. Конкурентоспособность отличной команды зависит от взаимного доверия и хорошего общения.

2.2 Сложность разработки программного обеспечения

Невозможно избежать этой сложности; все, что мы можем сделать, — это контролировать ее. Более 20 лет назад ведущие разработчики программного обеспечения осознали важность моделирования и проектирования предметной области. Хотя это и не указано четко, в объектном сообществе появилась новая тенденция, которую Эрик Эванс называет проектированием, управляемым предметной областью. Проектирование, ориентированное на предметную область, — это образ мышления и набор приоритетов, предназначенных для ускорения разработки проектов программного обеспечения, которые должны иметь дело со сложными областями.

Исходное намерение и цель: высокая сплоченность, низкая связанность.

2.3 Проблемы, решаемые с помощью DDD, по сравнению с проектированием традиционной архитектуры

Есть две основные проблемы, которые DDD должен решить:

1. Как разумно спроектировать структуру бизнеса?

2. Как сохранить согласованность бизнес-архитектуры предметной области системной архитектуры и добиться устойчивого расширения?

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

2.4 Основная идея предметно-ориентированного проектирования

1. Объединение модели и реального бизнеса

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

2. Унифицировать (деловой и технический) язык

• Модель — это центр общего языка, которым пользуются все члены команды. Благодаря корреляции между реализациями Моделей разработчики могут обсуждать программы на этом языке.
• Они могут общаться с экспертами в предметной области без необходимости использования переводчиков. А поскольку язык основан на Модели,Следовательно, мы можем уточнить саму Модель с помощью естественного языка.

3. Постоянное обучение команды, усвоение знаний и постоянное развитие системы.

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

Этот общий язык (модель) позволяет разработчикам и экспертам в предметной области эффективно сотрудничать при организации информации в модели.

4. Три принципа предметно-ориентированного проектирования

P1: Focus on your core domain.

※ Сосредоточьтесь на своих основных областях

P2: Iteratively explore models in a creative collaboration of domain practitioners and software practitioners.

※ Изучайте модели посредством сотрудничества и итераций.

P3: Speak a Ubiquitous Language within an explicitly Bounded Context.

※ Единый язык

2.5 Этапы проектирования на основе предметной области

5.1 Единый язык

Понятие одного и того же объекта может быть разным в разных контекстах.

Эта область настолько сложна, что единый язык возможен только в контексте сегментации.

В эпоху, когда UML был основным направлением моделирования, проектирование программного обеспечения было четко разделено на этапы объектно-ориентированного анализа (ООА), объектно-ориентированного проектирования (ООД) и объектно-ориентированного кодирования (ООП).

В реальных операциях работа ООД часто частично выполняется ООА и ООП, и существуют две отдельные модели: модель анализа и модель проектирования.

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

Проще говоря, это означает объединение языка бизнес-персонала и разработчиков и использование кода, чтобы почувствовать, что это, вероятно:

userService.love(Jack, Rose) => Jack.love(Rose)companyService.hire(company,employee) => Company.hire(employee)

5.2 Шторм событий и командный шторм в домене

Процесс анализа и методы моделирования предметной области:

5.2.1 Что такое события предметной области?

- Захватывайте то, что происходит в области, которую мы моделируем.

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

Ключевые моменты:

1. События, вызывающие обеспокоенность бизнеса ：полесобытие Должно быть ценно для бизнеса,Помогает сформировать полный замкнутый цикл бизнеса,То есть выездное мероприятие приведет к дальнейшим бизнес-операциям.

2. Используйте время «произошло», чтобы описать

3. Существует хронологический порядок

5.2.2 Как провести командный штурм?

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

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

5.2.3 Поиск агрегатов

Что такое агрегация

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

‣ Обеспечить бизнес-инвариант в пределах границы агрегации

‣ Только объекты внутри границ могут быть изменены через совокупные корни.

‣ Корень агрегата имеет глобальный идентификатор

5.2.4 Непрерывное исследование:

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

Метод, который действительно позволяет максимально расширить модель без ущерба для ее концептуальной целостности, называется «контекстом». Ограниченный контекст явно определяет контекст, в котором применяется модель. Установите границы модели на основе организации команды, использования различных частей программной системы и физического представления (код, схема базы данных и т. д.). Строго поддерживайте согласованность модели в этих границах, не беспокоясь и не сбиваясь с толку проблемами, находящимися за пределами границ.

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

2.6 Сервисное подразделение дизайна домена DDD

6.1 Режим ремонта (реконструкция устаревшей системы)

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

‣Режим ремонта подходит для существующих систем с нечастыми изменениями спроса.

6.2 Режим удушения (реконструкция устаревшей системы)

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

6.3 Принципы разделения услуг

Разделить в соответствии с границей контекста бизнес-границы

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

‣Разделение в соответствии с организационной структурой‣ Разделение услуг в соответствии с законом Конвея

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

На практике различные организации также применяют следующие принципы разделения услуг:

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

‣Разделить по границам технологической неоднородности‣Разделить систему по различным направлениям выбора технологий и развития

‣Разделено в соответствии с различными требованиями бизнеса к масштабируемости или надежности. ‣Разделено в соответствии с различными требованиями предприятия к безопасности.

2.7 Панорама DDD

1. Стратегический дизайн

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

2. Тактическая конструкция

3. Процесс работы панорамного обзора

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

2.8 Модель предметной области

Революционный аспект DDD заключается в том, что модель предметной области точно отражает бизнес-язык, в то время как традиционные модели транзакционного программирования, такие как J2EE или Spring+Hibernate, заботятся только о данных. Эти объекты данных не имеют никаких бизнес-методов, кроме простых методов установки/получения. сравниваются с моделью кровопотери.

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

1. Классификация и характеристики моделей

• Модель кровопотери: Модель содержит только определение данных и методы получения/установки.,Бизнес-логика и логика приложения размещаются на уровне сервисов. Этот тип класса в Java называется POJO.,В .NET это называется POCO.
• Модель анемии: Модель анемии содержит некоторую бизнес-логику.,Но он не включает бизнес-логику, основанную на уровне персистентности. Эта часть бизнес-логики, которая зависит от уровня персистентности, будет размещена на уровне сервиса. Это можно увидеть,Объекты предметной области в модели Anemia не зависят от уровня персистентности.
• Модель перегрузки: Модель перегрузки содержит всю бизнес-логику.,Включает бизнес-логику, основанную на уровне персистентности. так,Уровень поля, использующий модель перегрузки, зависит от уровня персистентности.,Проще говоря, это UIслой->Служитьслой->полеслой↔длительныйслой。
• Модель Blowing Blood: Модель Blowing Blood предназначена для размещения в модели другой логики приложения (например, авторизации, транзакций и т. д.), которую бизнес-логика не хочет закрывать. предметной областисередина。Ощущение раздутости Модель Вместо этого это другой вид кровопотери.Модель,Потому что сервисный уровень исчез,Уровень домена выполняет работу уровня обслуживания.,В итоге ничего не изменилось.

2. Понимание четырех моделей

В традиционной модели разработки, основанной на модели анемии, уровень обслуживания содержит две части: класс обслуживания и класс BO является моделью анемии и содержит только данные и не содержит конкретной бизнес-логики. Бизнес-логика сосредоточена в классе Service. В модели разработки DDD, основанной на модели перегрузки, уровень обслуживания состоит из двух частей: класса обслуживания и класса домена. Домен эквивалентен BO в модели анемии. Однако разница между Domain и BO заключается в том, что он разработан на основе модели перегрузки и содержит как данные, так и бизнес-логику. И класс обслуживания становится очень тонким.

Подводя итог, традиционная модель развития, основанная на модели анемии, делает упор на обслуживание и делает упор на BO; модель развития DDD, основанная на модели перегрузки, делает упор на обслуживание и сферу деятельности;

• Преимущества и недостатки модели анемии:

Преимущества этой модели: 1. Каждый уровень имеет одностороннюю зависимость, четкую структуру, его легко реализовать и поддерживать. 2. Конструкция проста и удобна, а базовая модель очень стабильна. Недостатки этой модели: 1. Логика домена персистентности, от которой тесно зависит объект домена, разделена на уровень службы, что кажется недостаточно объектно-ориентированным. 2. Уровень службы слишком тяжелый.

• Преимущества и недостатки модели конгестии:

Преимущества этой модели: 1. Она больше соответствует принципам ООП. 2. Уровень обслуживания очень тонкий, играет только роль фасада и не занимается DAO. Недостатки этой модели: 1. DAO и объект домена образуют двустороннюю зависимость. Сложная двусторонняя зависимость приведет ко многим потенциальным проблемам. 2. Как разделить логику сервисного уровня и логику доменного уровня очень неоднозначно. В реальных проектах из-за разницы в уровне дизайнеров и разработчиков это может привести к хаосу и беспорядку во всей структуре. Характеристики инкапсуляции транзакций уровня службы. Уровень службы должен предоставлять соответствующие методы инкапсуляции транзакций для логики всех объектов домена. В результате служба полностью переопределяет всю логику домена, что очень громоздко. инкапсуляция Службы эквивалентна преобразованию объектно-ориентированной логики в процесс TransactionScript службы. ООП, над реализацией которого так усердно работала модель перегрузки на уровне домена, стала процедурной на уровне обслуживания.

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

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

2. Если элемент не отделен от управления уровнем персистентности, например, pm JDO, то itemDao.update(this) не требуется, что означает, что элемент извлекается из базы данных во время транзакции, и объект удаляется из базы данных во время транзакции; Срок декларирования не превышает текущий объем сделки.

3. Если элемент отделен от уровня персистентности, то есть когда жизненный цикл элемента превышает объем транзакции, то методы персистентности, такие как обновление или присоединение, должны быть явно вызваны. В это время все должно быть так, как сказал Роббин. Для этого используется вторая модель.

• Плюсы и минусы вздутой крови Модель:

Преимущества этой модели: 1. Упрощенное многоуровневое представление. 2. Также считается, что она соответствует ОО. Недостатки этой модели: 1. Многие сервисные логики, не являющиеся логикой предметной области, также принудительно помещаются в объект предметной области, что приводит к нестабильности объектной модели предметной области. 2. Объект предметной области предоставляет слишком много информации веб-слою, что может привести к непредвиденным последствиям. побочные эффекты.

оценивать:

Среди этих четырех моделей не следует защищать модель кровопотери и модель набухания крови. Модель анемии и модель перегрузки технически осуществимы.

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

Вторая модель — это модель, которую всегда отстаивал Мартин Фаулер, и фактически эта модель использовалась в реальных проектах. Однако я чувствую, что эта модель все еще не идеальна, поскольку вам все еще нужен уровень бизнес-логики для инкапсуляции всей логики предметной области, которая очень многословна, а интерфейс объекта бизнес-логики недостаточно стабилен. Если не учитывать возможность повторного использования объектов бизнес-логики (повторное использование объектов бизнес-логики не может быть хорошим), многие люди просто удаляют слой xxxManager, а код действия на веб-уровне напрямую вызывает xxxDao, и в то же время транзакция контейнера конфигурация управления. Поднимитесь на уровень действий. Caveatetemptor Hibernate — типичное применение этой архитектуры.

Третья модель является очень противоположной. В рамках этой модели объект домена и DAO образуют двусторонние отношения зависимости, которые невозможно протестировать без инфраструктуры. Более того, сервисы уровня бизнес-логики также связаны с состоянием. объект слоя персистентности, который будет Это приводит к высокой степени сложности, плохой гибкости и плохой ремонтопригодности программы. Возможно, в будущем, если объект предметной области, управляемый O/R Mapping, благодаря технологическому прогрессу, станет достаточно динамичным и долговечным, эта модель станет идеальным выбором.

Точно так же, как популярность O/R-отображения делает возможной вторую модель, модель предметной области Мартина Фаулера, или наша вторая модель идеальна? Конечно нет. Далее мы разберем его недостатки и возможные пути решения.

(Подробные примеры кода и анализ см. по адресу: https://my.oschina.net/u/1999167/blog/1841997)

3. Почему традиционная модель развития, основанная на моделях анемии, так популярна?

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

Однако почти все веб-проекты сейчас основаны на этой модели разработки. Даже официальная демо-версия Java Spring написана по этой модели разработки.

4. Приросты и потери модели полной гиперемии или вздутия живота DDD.

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

Итак, как вы будете разрабатывать свое программное обеспечение? Это постоянство невежества: дизайн, независимый от постоянства. Без базы данных модель предметной области должна разрабатываться на основе самой программы. Здесь студенты, которым нравятся шаблоны проектирования, могут проявить свои таланты. Среди процессно-ориентированных, функционально-ориентированных и объектно-ориентированных языков программирования объектно-ориентированный, несомненно, является лучшим способом моделирования предметной области.

Классы и таблицы чем-то похожи (многие думают, что таблицы и классы соответствуют друг другу, а строки и объекты соответствуют друг другу). Лично я категорически не согласен с таким эквивалентным отношением, которое прямо делает бессмысленным проектирование программного обеспечения. Классы и таблицы имеют следующие существенные различия. Эти различия существенно различаются в богатстве выражений моделирования предметной области. Благодаря инкапсуляции, наследованию и полиморфизму выражение моделей предметной области становится гораздо более ярким, а выражение принципов SOLID — гораздо более ярким. более ярким. Соответствие будет гораздо строже.

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

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

2.9 Практика управления предметной областью в бизнес-анализе среднего уровня

1. Спецификации архитектуры приложения в области DDD бизнес-центра.

2. Видение использования DDD-моделирования предметной области в бизнес-центре (многоуровневая архитектура)

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

4. Построение границ модели структуры данных

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

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

03

Рекомендуемые руководства и документация

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

Banqiao Dahua DDD (https://www.jdon.com/ddd/ddd-domain.html) кратко рассказывает о некоторых основных характеристиках DDD на просторечии, просто для грамотности! SQL базы данных следует использовать с осторожностью.

Десять лет исследований DDD Банкяо: «Путь проектирования сложного программного обеспечения: комплексный анализ и практическая практика предметно-ориентированного проектирования» (https://www.jdon.com/54881.html), любезно предоставлено Machinery Press

Баньцяо: Почему Bounded Context в DDD переводится как «ограниченный контекст»? (https://www.jdon.com/55608.html)

Баньцяо: Пространство проблем и пространство решений в DDD — ложное утверждение (https://www.jdon.com/55682.html)

Случай с ловушкой программирования бизнес-кода — jaxenter (https://www.jdon.com/53806.html) Очень распространенные неподходящие методы программирования, ловушки, вызванные моделью кровопотери

Сравнение двух методов анализа и проектирования, объектно-ориентированного моделирования и моделирования баз данных (https://www.jdon.com/mda/oo_relation.html). Проектирование, основанное на базе данных, и объектное моделирование — это две основные фракции, определяющие разные судьбы Программное обеспечение. Какой из них Может ли программное обеспечение быть более живым, а обслуживание и расширение более удобным? Более масштабируемый?

Дядя Боб: Сначала спроектируйте поведение объекта, а затем спроектируйте структуру таблицы базы данных! (https://www.jdon.com/55056.html) Советы от дяди Боба, мастера разработки программного обеспечения и одного из создателей Agile.

Объектно-ориентированное и предметное моделирование (https://www.jdon.com/mda/modeling.html). Согласно опросу, около 70% программистов в настоящее время используют объектно-ориентированный язык для написания традиционного процедурного программного обеспечения и не имеют полного объектно-ориентированного мышления. Обучение и обучение методам лежат в основе этой статьи. В этой статье представлены независимые взгляды и четкие взгляды на некоторые распространенные проблемы разработки программного обеспечения.

Моделирование предметной области Evans DDD (https://www.jdon.com/mda/dddcase2.html). Как уточнить модели вместо таблиц данных, а затем уточнить объекты модели, чтобы они могли отражать основную суть концепций предметной области, — это сложный процесс. Evans DDD — революционная идея программного обеспечения, предложенная в 2004 году.

Практический DDD (Evans DDD: Проектирование, управляемое предметной областью) (https://www.jdon.com/mda/ddd.html) Моделирование предметной области — это художественный, а не математический метод. Он используется для решения сложных программных задач. быстро справляться с изменениями.

Проектирование на основе модели предметной области (Evans DDD) Извлечение модели (https://www.jdon.com/mda/dddcase2.html)

Проектирование программного моделирования (https://www.jdon.com/mda/communicating-design.html)

Как обнаружить богатые объекты перегрузки с помощью ответственности и сотрудничества? Модель кровопотери и модель анемии — главные враги DDD. Как спроектировать бизнес-поведение в соответствии с принципом SOLID (https://www.jdon.com/tags/39825) и принципом GRASP (https://www). .jdon.com/tags/44849)? В этой статье приводятся некоторые конкретные подробности конкретной практики DDD, которая является хорошим способом выполнения объектно-ориентированного анализа и проектирования вместе с DDD.

Унифицированный язык описания бизнес-моделей (https://www.jdon.com/44416.html) является важной особенностью и целью DDD.

Пример DDD CQRS и источника событий: футбольный матч

Вариант реализации DDD + CQRS + Event Sourcing в сочетании с кодом и теоретическим объяснением.

Случай DDD системы контейнерного парка

Практический консалтинговый пример DDD-проектирования на основе предметной области для транспортной системы крупной портовой компании в Шанхае.

Реализация хранилища DDD: руководство Spring Data JDBC (https://www.jdon.com/springboot/spring-data-jdbc.html)

Последствия отказа от использования DDD: почему мы перестали переходить на микросервисы? (https://www.jdon.com/52922.html)

Пример использования агрегации DDD для обнаружения скрытых бизнес-правил: бизнес-реализация транзакций базы данных (https://www.jdon.com/53449.html)

Переход к проектированию, ориентированному на предметную область: как использовать DDD для перехода от монолитной системы к микросервисам для создания бизнес-платформы или промежуточной платформы? (https://www.jdon.com/53462.html)

Крупномасштабный пример микросервисов DDD+: как Uber перешел от сложных микросервисов RPC к бизнес-ориентированной микросервисной архитектуре DOMA? (https://www.jdon.com/54664.html)

Как Shopify, крупная глобальная компания электронной коммерции, использует DDD для модульности своей монолитной архитектуры? (https://www.jdon.com/55003.html)

Дополнительные темы #DDD по доменному дизайну и тематические мероприятия (https://www.jdon.com/tags/272)

04

Подвести итог

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

‍‍

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

Справочная литература в блоге: (Не забывайте копать колодцы, когда пьете воду)

• Краткое обсуждение архитектурных шаблонов MVC, MVP и MVVM: https://draveness.me/mvx.
• Блог Шан Шаня Руо Шуя: http://deshui.wang/
• Путь к продвижению для CRUD-инженеров: https://zhuanlan.zhihu.com/p/25442175
• Естественное сопротивление объектов и баз данных: https://www.jdon.com/mda/oo-reltaion2.html
• Commands & Events instead of CRUD — Part 1: Commands：https://hackernoon.com/commands-events-instead-of-crud-part-1-commands-17f4c7aee33b
• Блог Тан Сюэхуа: https://www.cnblogs.com/netfocus/
• There is No U in CRUD：http://jlhood.com/there-is-no-u-in-crud/
• Event sourcing vs CRUD：https://community.risingstack.com/event-sourcing-vs-crud/
• Практика дизайна Alibaba Freshhema на местах: https://www.infoq.cn/article/alibaba-freshhema-ddd-practice
• Стратегия DDD: оперативность архитектурного проектирования: https://zhuanlan.zhihu.com/p/30878497
• Используйте DDD для создания своего REST API, а не CRUD: http://blog.didispace.com/use-ddd-design-rest-api/
• DDD & co., part 1: What's wrong with CRUD：https://www.thenativeweb.io/blog/2017-10-25-09-46-ddd-and-co-part-1-whats-wrong-with-crud/
• Окончательный шаг DDD — на основе опыта: https://insights. Thoughtworks.cn/ddd-by-experience/
• Обзор доменно-ориентированного дизайна: http://zhangyi.xyz/overview-of-ddd/
• Refactoring from anemic model to DDD：https://blog.pragmatists.com/refactoring-from-anemic-model-to-ddd-880d3dd3d45f
• Почему DDD — лучшая практика для проектирования микросервисов: https://www.jianshu.com/p/e1b32a5ee91c
• Практика доменно-ориентированного дизайна в развитии интернет-бизнеса: https://kb.cnblogs.com/page/586236/
• Проектирование, управляемое доменом (DDD: Проектирование, управляемое доменом): https://www.jdon.com/ddd.html
• Мое мнение о доменно-ориентированном дизайне: https://www.jdon.com/39844.html
• Практика и размышления о предметно-ориентированном дизайне: https://www.jdon.com/45286.html
• Случай #DDD: https://www.jdon.com/tags/19145 Ограниченный контекст #DDD: https://www.jdon.com/tags/15977 Агрегация #DDD: https://www.jdon.com / теги/8976
• #Субъект DDD: https://www.jdon.com/tags/307 Объект значения #DDD: https://www.jdon.com/tags/309 Сервис #DDD: https://www.jdon.com/ теги/677
• Модель складирования #DDD: https://www.jdon.com/tags/238 Модель спецификации спецификации #DDD: https://www.jdon.com/tags/766
• # доменное событие: https://www.jdon.com/event.html #EventStorming: https://www.jdon.com/eventstorming.html Архитектура #CQRS: https://www.jdon.com/cqrs html.

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

▪

Основные возможности: ведение основных пользовательских данных, моделирование поведенческих данных, анализ портретов пользователей и формулирование точных маркетинговых стратегий.

▪Функциональная поддержка: система роста участников, стратегия расчета уровня, система долевого участия и поддержка маркетинговых возможностей нижнего уровня.

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