Автор: Брат Сяо Фу блог：https://bugstack.cn

Осаждайте, делитесь, растите, чтобы вы и другие могли что-то получить! 😄

Всем привет, я Брат, технический менеджер UP. Фу。MVC объяснил,ДДД объяснил. Следующая глава,Поговорим о реконструкции отMVCприезжатьDDD!

Чтобы избежать путаницы понятий и облегчить объяснение следующего содержания, сначала подтвердите понимание концепции DDD;

1. Domain-driven design (DDD) is a major software design approach. Из Википедии. ДДД это своего рода дизайн программного обеспеченияметод。
2. Методы проектирования программного обеспечения охватывают;、Модель、рамка、Методология, основная деятельность включает моделирование、тест、проект、развивать、развертывать、поддерживать。Из Википедиидизайн программного обеспеченияВведение закрытой информации。
3. Так существуют в нынешних условиях,Сравнение MVC и DDD,Только фреймворковая структура реализации ПО,Это не всестороннее сравнение дизайна мышления и моделирования мышления. Итак, если читатели объяснят сравнение MVC и DDD некоторым другим партнерам,,Также необходимо объяснить контекст.,Не зацикливайтесь на теории без необходимости,Значимость общения и обсуждения игнорируется.

Итак, далее в этом контексте мы объясним реконструкцию MVC и DDD;

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

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

Как мы все знаем, иерархическая структура MVC представляет собой анемичную модель, которая разделяет «состояние» и «поведение» на различные структуры пакетов для разработки и использования. Объекты po, vo и enum написаны в домене, а реализация функциональной логики написана в сервисе. Именно потому, что структура MVC не имеет большого количества ограничений, скорость ранней доставки очень высока. Однако с длительной итерацией системного проектирования анемичные объекты стали использоваться многими службами перекрестно, а сервисные службы также звонили друг другу. Отсутствие метода контекстной разработки приводит к тому, что долгосрочные итерации проектов MVC постепенно приводят к серьезному повреждению.

Коррумпированная основа разработки MVC,«Просто существование» — это перекрестная путаница объектов, сервисов и компонентов. Чем дольше время,Тем более он коррумпирован.

Существуют иерархическая структура MVC, подобная тому, как если бы мы собрали всю одежду в большом гардеробе, а все штаны — в большом шкафу для хранения вещей. Одежда и брюки (предмет),Очень экономит место при редком использовании,потому что другие тоже могут носить твои штаны,Используйте его повторноразвиватьочень быстро。Но со временем,Ситуация становится все более хаотичной. 🤨 Пара брюк становилась все больше и больше, и все их носят.

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

Итак, далее мы сосредоточимся на следующем: как выполнить облегченную реконструкцию из MVC в DDD. 🍻

В конце статьи дается практическое объяснение рефакторинга кода с MVC на DDD. Эта статья также представляет собой практическое объяснение рекомендаций по архитектурному кодированию для MVC и DDD.

1. Чему можно научиться?

Эта статья более практична и может быть реализована DDD Обмен знаниями также начинается с MVC приезжать DDD Объяснение реализуемых решений. существуют Эта статья середина познакомит вас DDD Многоуровневая структура под архитектуру, панорама вызова и что очень важно MVC приезжать DDD Как это должно быть отображено и закодировано. Итак, следующая серия содержания представляет собой знания, которые вы можете получить;

1. Проектирование на основе домена DDD, поясняется соответствующая многоуровневая структура. Охватывает отношения вызовов, зависимости, преобразование объектов и функциональное разделение каждого уровня. ——Просто и понятно.
2. DDD Вызовите панораму, вызовите вид с комплексной структурной связью и разверните его. DDD Связь кровообращения. С этой точки зрения вы будете знать более четко DDD изструктура ссылки на звоноки Каждый код должен быть написанприезжатьэтот слой。
3. MVC картографирование DDD После плана корректировки выжить с наименьшими возможными издержками, пусть MVC Структура имеет DDD Реализация идеи предметно-ориентированного проектирования. Такие корректировки могут предотвратить повреждение старых проектов и в определенной степени улучшить качество кодирования. В то же время он также готовится к последующим действиям. MVC приезжать DDD Для миграции заложите основу.
4. MVC и DDD — это скелет инженерного проектирования, а принципы проектирования и шаблоны проектирования — это плоть и кровь инженерной реализации. Поэтому шаблоны проектирования также находятся в центре внимания этой статьи.
5. Набор практических курсов с открытым исходным кодом, объясняющих существование; DDD Архитектура середина, различные технологические стеки Dubbo, MQ, Redis, Zookeeper; - Используйте средний уровень конфигурации.—— В противном случае вы могли бы даже не знать ни одного MQ Куда поставить существование при отправке сообщения. Понятно DDD Благодаря многоуровневой архитектуре эти вещи будут классифицированы очень четко.

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

2. Многоуровневая архитектура (DDD)

существовать DDD На уровне архитектуры домен Самый важный модуль одновременно является и самым большим. Все остальные модули вращаются вокруг него. все domian Каждый модуль домена содержит полный набор моделей; - Модельный объект, сервис - Служба обработки, и когда существуют потребности в работе базы данных, вводят соответствующие IRepository - Складские услуги. этот domain Реализация,Это как осознать мешок с динамитом,Взрывной пакет с порохом, вести, Оберточная ткань и другие материалы упаковываются вместе.

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

• Пакет приложений - приложение：Это запуск приложенияи Конфигурацияслой,например, некоторые aop вырезать или config Конфигурация,и упакованные изображениясуществовать Этот уровень обработки。Вы можете думать об этом как о специальном начале Служитьижитьсуществоватьиз。
• Определение интерфейса — API：потому чтоMicroservices середина процитировано RPC Информация описания внешнего интерфейса необходима, то есть когда необходимо представить вызывающую сторону существуиспользовать. Jar Package, чтобы вызывающая сторона могла полагаться на определение интерфейса как прокси.
• Инкапсуляция домена — триггер：триггерный слой,Обычно также называется уровнем адаптера-адаптера. Используется для реализации интерфейса, приема сообщений, выполнения задач и т. д. Итак, для такой операции,Здесь это называетсятриггерный слой。
• Расположение доменов [необязательно] — регистр：Уровень оркестрации домена,Обычно большие и сложные проекты.,Для лучшей защиты от коррозии ипо обеспечивает универсальное обслуживание.,Обычно логика в поле уровня случая/приложения для домена добавляется для инкапсуляции и комбинированной обработки. Но для некоторых небольших проектов,Этот слой можно полностью удалить. Небольшое количество одноуровневых преобразований объектов.,Стоимость обслуживания кода будет значительно снижена.
• Инкапсуляция домена - домен：поле Модель Служить,Это очень важный модуль. Как бы вы ни делали многоуровневую архитектуру DDD,Домен определенно хранится в существовании. существовать На первом этаже середина будут разделены выездные службы,существоватькаждый Служить Сумкасерединабудет【Модель、склад、Служить】так3часть。
• Складские услуги - инфраструктура：Базаслой зависит от domain Слой домена, потому что чтосуществовать domain Уровень определяет складской интерфейс, необходимый для существования базовых поставок. слоя。Это инверсия зависимостейиздизайнерский подход。всеизскладирование、интерфейс、сообщение о событии,все будет в порядкечерез инверсию зависимостейиз Способруководитьвызов。
• Определение типа — шлюз：длявнешнийинтерфейсизвызов,Также отуровень выделить отдельный специализированный gateway Уровень шлюза для инкапсуляции внешних RPC/HTTP Вызовы других типов интерфейсов.
• определение типа - типы：Универсальныйопределение типа слоя, существующего в нашей системе развития середина, будет много типов определений, в том числе базовых; Response、Constants и перечисление. На него будут ссылаться другие слои. (На этом слое нет изображения приезжать середина)

Таким образом, это инженерная иерархическая структура модели в соответствии с идеей архитектуры DDD. Ключевые моменты предметно-ориентированного проектирования архитектуры DDD включают более четкие структурные границы, акцент на контекстных вызовах, а также разделение бизнес-функций и базовой поддержки. Словом, каждый выполняет свои обязанности. Итак, учитывая такую ​​четкую структуру проекта, как преобразовать старый проект MVC в DDD? Далее давайте сосредоточимся на этом.

три、проект Рефакторинг(MVC->DDD)

На практике доказано, что это не стоит слишком дорого, MVC может естественно DDD Преобразование структуры модели для инженерных расслоений. Ключевой момент — не менять зависимости исходных инженерных модулей и заменять анемичные domain слой объекта,Создан для насыщенияизструктура。для domain оригинальныйсуществовать MVC слоистыйструктурасередина,Это зависимый слой,Его можно использовать с другими уровнями для реализации решений по инверсии зависимостей.。Как показано на рисунке；

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

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

1. service реализация серединасервиса с характеристиками предметной области, абстрагирующая исходную анемичную модель проживания domain середина。существовать domain Добавлена ​​многослойная середина xxx、yyy、zzz слоистыйполе Сумка,Реализуйте различные функции соответственно。Обратите внимание, что каждый иерархический доменный пакет содержит полные модули, необходимые для доменных служб DDD.
2. service Основные функциональные компоненты середина, такие как кэширование Redis, Конфигурациясередина и т. д., мигрируют приезжать. dao слой. Здесь мы ставим dao Просматривается как уровень инфраструктуры。это связано с domain Отношение вызова на уровне домена представляет собой инверсию зависимостей. То есть domain Интерфейс определения слоев, дао слой зависит от domain Определите интерфейс и реализуйте инверсию зависимостей для реализации интерфейса.
3. В конечном итоге сама служба используется в качестве уровня приложения/кейса для вызова уровня домена для обработки оркестрации службы.

Потому что так бывает, что в иерархической структуре MVC сервис и dao также зависят от домена, что соответствует иерархической структуре DDD. Следовательно, после разделения кода посредством такого сопоставления для реализации структуры вызова структура проекта не изменится. Таким образом, пока структура проекта не изменится, наши затраты на трансформацию — это только затраты на стиль кодирования и миграцию старого кода.

MVC в иерархической структуре export слой RPC Уровень определения интерфейса состоит из web реализация слоя. сеть да service вызов. То есть DDD Вызывается в иерархической структуре application Договариватьсяхорошийиз Служить。этотчасть Никаких изменений не требуется。Но если ваш первоначальный проект domain Если он также утек, вам необходимо перенести соответствующий пакет в приезжать. export потому что domain В пакете слишком много основных объектов и свойств, включая объекты сохранения базы данных. Ничего из этого не должно быть раскрыто.

MVC слоистыйсередина,потому что Существует потребность во внешнем RPC вызов интерфейса, поэтому будет отдельный слой RPC Для инкапсуляции интерфейсов других сервисов. Этот слой лоскутный domain Уровень использования домена может быть определен adapter Интерфейс адаптера, посредством инверсии зависимостей, существует rpc реализация слоя domain Вызывающий интерфейс, определенный слоем.

также dao слой,существовать MVC Первоначально структура была относительно простой. Однако после трансформации необходимо будет изменить основные Redis использовать、Конфигурациясерединаиспользовать,Все мигрируют на уровень перемещения дао. потому что Исходная служба существования Для слоев доменного уровня вызывает эти базовые услуги, которые не доступны для проживания.,ии не соответствует Служитьфункциональные границыизразделять。

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

приезжать Здесь мы прояснили вопрос иерархической структуры. от MVC Изменить структуруприжаез DDD назад,Каково вызывающее звено инженерной модели середина? Далее расширяем архитектуру,Посмотрите на детали.

4. Иерархические ссылки вызова

Далее мы поставим Многоуровневая архитектура DDD имеет плоскую структуру.,взгляниотодининтерфейс Реализацияприезжатькаждыймодульслоистыйсерединаизвызов链路关系是什么样из。таксуществоватьбудь собойизкодразвиватьсередина ХОРОШОссылкаприезжатьчто должно бытьиз Функциональное распределениеприезжатькакой модульсерединаиметь дело с。

отAPP-уровень、триггерный слой、приложениеслой,Эти три блока в основном инкапсулируют контекстную логику уровня домена и триггера (MQ, HTTP, JOB).,И, наконец, уровень существования приложения середина упаковывается и публикуется в Интернете. Эта часть посвящена обработке использования.,Так что слишком сложных операций не будет.

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

Возьми это Приходить Давайте представим этополеслойи Базаслойизмодуль Обязанности；Поток да слонов под картинкой середина,Вы можете обратить внимание на Вниз.

1. Уровень обслуживания домена

мы можем быть domain Уровень предметной области представляет собой структуру модели перегрузки, существующую domain На уровне домена может быть несколько пакетов домена. В идеале, конечно, если ваш DDD Разделите особенно чистый новый проект, а затем, возможно, domain Сразуодинполе。Но большойчасть Ши Вэй Служитьиз Разделение не будет столь детальным из соображений стоимости.,Также есть реконструкции некоторых старых проектов.,В одном проекте несколько направлений,Соответствующее решение — создать несколько иерархических пакетов одного уровня в рамках одного проекта. Например, пакет полей счета, пакет кредитных полей, пакет полей расчетов и т. д.,Агрегация внутри каждого пакета реализует разные функциональные возможности.

Пакет доменов в каждом домене включает в себя модель модели, складирование, интерфейс, обработку событий и услуг.

модель объекта модели;

• агрегат: объект агрегации, совместная организация объектов сущностей и объектов значений, является объектом агрегации.
• Сущность: объект сущности. В большинстве случаев объект сущности (Entity) и объект персистентности базы данных (PO) имеют отношения 1v1, но существуют также отношения 1vn для инкапсуляции некоторой атрибутивной информации.
• valobj: объект значения, объект, идентифицируемый значением атрибута объекта. Путем «Реализации доменно-ориентированного проектирования»

repository Складские услуги；от базы данных и других источников данных для получения данных передаваемый объект может быть агрегатным объектом, объектом сущности, а возвращаемый результат может быть объектом сущности или объектом значения. потому что что Складские услуги состоят из базового слоя (инфраструктуры) Уровень эталонного домена (домен) представляет собой структуру инверсии зависимостей, но он может естественным образом изолировать объект персистентности базы данных PO от ссылок.

adapter Интерфейсные услуги — это другие услуги, которые полагаются на аутсорсинг; HTTP/RPC Вызов инкапсуляции интерфейса, существование через domain Уровень домена определяет интерфейс адаптера, который затем зависит от domain уровень инфраструктуры или отдельный дополнительный уровень, предназначенный для обработки интерфейсов для достижения domain Определите интерфейс адаптера для завершения зависимости HTTP/RPC Выполните обработку инкапсуляции.

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

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

2. Уровень инфраструктуры

обеспечивает постоянство базы данных、Установите Центр конфигурации Redisi для поддержки данных、по отправке сообщения о событии、поставлятьвнешний Служитьинтерфейс Инкапсуляция。总之этот一слойизядерный Сердцеглазизто есть Дажехорошийиз Вспомогательный domain Уровень предметной области завершает разработку функций предметной области.

Вызывающий метод — инверсия зависимостей,такжето естьУровень обслуживания доменаопределениеинтерфейс,уровень инфраструктурыВыполняем реализацию функции。такможет быть эффективнымизизбегать Базауровень инфраструктурысерединаиз Объектиностранныйнезащищенный,Например, постоянные объекты базы данных.,существует такая многослойная структурасередина,Естественный защищенный базовый слой середина,Его нельзя внедрить извне.,В противном случае возникнет круговая зависимость.

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

3. Введите слой объекта

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

5. Только что поменял виллу

от MVC приезжать ДДД, есть одна вещь, которую мы должны четко понять.

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

Если вы все же переместите исходный плохой код в новую многоуровневую архитектуру, это будет эквивалентно перемещению старой мебели, одежды, обуви и головных уборов из старого дома. Итак по дизайну программного обеспеченияизв принципе；Разделяй и властвуй, абстракция и знание,Знания середина — это применение принципов проектирования и шаблонов проектирования. Итак, если вы хотите хорошо писать код,Это должно быть сделаноDDD + шаблоны проектирования,Только тогда вы сможете действительно хорошо написать код. Следующий,Брат Фу приведёт вам ещё один пример: использовать режим существования. DDD Аргументы в пользу рефакторинга в иерархических структурах.

6. Рефакторинг существующего кода

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

так,Если нет разумного использования знаний проектирования для улучшения кода,Поэтому даже если разделить границы процесса, сохранится четкая архитектура.,Также сложно создавать поддерживаемый код. Наиболее часто используемые шаблоны проектирования,Не что иное, как сочетание фабрик, стратегий и шаблонов;,Небольшое количество людей будет использовать режимы цепочки ответственности, строителя и комбинирования. Затем следующий,существование имеет общий шаблон проектирования с потокомиспользовать,让大家可以有一份可ссылкаизпроектдизайн кода。

1. Настройка сцены

Здесь мы настраиваем сценарий увеличения квоты. Думаю, все использовали кредитную карту 💳,Имеет начальную квоту,Последующее использованиесередина будет увеличиваться по мере накопления кредита и потребления.,Увеличьте сумму. Увеличение квоты требует серии проверочных решений и окончательного увеличения квоты. Процесс заключается в следующем;

Такая схема движения,Он наш партнер по развитию бизнеса.,Я часто смотрю приезжать. Сделайте ряд процессуальных суждений и процессов,Затем выполните определенную функцию. Проще говоря,то есть if···else Напишите код и проверьте его один за другим. Но со временем вы обнаружите, что код становится особенно запутанным. Основная причина заключается в том, что различные решения, принимаемые в поддержку завершения бизнеса, являются нестабильными факторами и будут постоянно корректироваться по мере изменения бизнеса. Иногда даже прямо отваливается. Но в вашем коде только что появилась одна ошибка // В компании говорят, что она пока не будет доступна, но вы не смеете ее удалять!Сразу像有首歌唱из🎤：«Спрос остается на низком уровне,Ваш код становится все длиннее и длиннее. Звук конских копыт, исчезающий вдалеке,Вызовите свои ошибки. "

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

2. Текущий статус кода

Один интерфейс, одна реализация и один код реализации. Один кусок за другим, количество строк кода две-три тысячи.

Большинство из нас существуют MVC проектслоистыйструктура Вниз,Участвовать в разработке кода,По сути, он определяет интерфейс,Просто напишите кусок функционала для его реализации. Функциональная реализациясередина,Если посмотреть приезжать, то там уже готовый интерфейс.,Просто используйте его напрямую. Все реализации не будут основаны на интерфейсах, абстракциях, шаблонах и т. д.,такфинальныйтакизкод腐化изочень серьезно。

3. Повторный слой

Перед реконструкцией сначала объясните новый процесс наслоения, как показано на рисунке;

• Прежде всего, существуют оригинальные domain Модель анемии середина, добавьте соответствующий пакет полей. кредит Вы можете создать свои собственные пакеты других доменов. после domain Он предназначен для модели гиперемии.
• после,Реализуйте собственную бизнес-логику в рамках пакета доменов.,Обратите внимание, что это необходимо реализовать с использованием шаблона проектирования приезжать. Реализация кода середины требует запроса данных, использования кэша и вызова интерфейса.,Все используют инверсию зависимостей для создания базового уровня/уровня интерфейса.,Приходитьпоставлятьспецифический Реализациялогика。и domain Уровень просто определяет интерфейс ииспользовать Spring Инъекцию выполняют с использованием.

4. Рефакторинг кода

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

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

• первый,определениеодин Принять корректировку квотыизинтерфейс。потому что Квотаиз Корректирование,Сумкавключать；Увеличить сумму、Снизить мощность。так Не пишите свое имяиз Слишком мертв。
• после,Интерфейсы реализуются абстрактными классами. существующий абстрактный класс середина определяет всю связь между вызовами,И добавьте несколько общедоступных классов данных для поддержки логики.,Укажите категорию поддержки приезжать. Этот и весенний дизайн очень похожи.
• после,потому Проверка правил предназначена для поддержки основного процесса и часто меняется вместе с бизнесом. Тогда нет необходимости существования основного бизнес-процесса середина, использовать if···else Нанесите штукатуркуиз写код,Его следует демонтировать. Итак, здесь мы разрабатываем проверку правил, реализуемую в режиме стратегии.,и пройти мимо фабрикииностранныйпоставлять Служить。
• наконец,этот些东西零件добрыйизвсеиметь дело схорошийназад。Вот и всесуществоватьабстрактныйдобрыйиз子добрый实现серединаруководитьвызовиметь дело с Понятно。

5. Представление кода

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

public AdjustAssetOrderEntity acceptAdjustAssetApply(AdjustAssetApplyEntity adjustAssetApplyEntity) {
    // 1. Проверка параметров
    this.parameterVerification(adjustAssetApplyEntity);
  
    // 2. Запросить данные формы заявки. Если они были сохранены, они будут возвращены напрямую.
    AdjustAssetOrderEntity orderEntity = queryAssetLog(adjustAssetApplyEntity.getPin(), adjustAssetApplyEntity.getAccountType(), adjustAssetApplyEntity.getTaskNo(), adjustAssetApplyEntity.getAdjustType());
    if (null != orderEntity) {
        log.info("pin={} taskNo={} Примите заявку и получите форму заявки на въезд в депозит, существующую в течение середина. ", adjustAssetApplyEntity.getUserId(), adjustAssetApplyEntity.getTaskNo());
        return orderEntity;
    }
  
    // 3. Следующий процесс обрабатывается в рамках распределенной блокировки прибытия [избегая повторного запроса: Входить]
    String lockId = genLockId(adjustAssetApplyEntity.getAdjustType(), adjustAssetApplyEntity.getUserId());
    try {
        // 3.1 Распределенная блокировка: блокировка
        long state = lock(lockId);
        if (0 == state) {
            throw new AccountRuntimeException(BizResultCodeEm.DISTRIBUTED_LOCK_EXCEPTION.getCode(), "Исключение распределенной блокировки, обработка текущего поведения пользователя середина.");
        }
      
        // 3.2 Запрос на счет
        UserAccountInfoDTO userAccountInfoDTO = queryJtAccount(adjustAssetApplyEntity.getUserId(), adjustAssetApplyEntity.getAccountType());
      
        // 3.3 Базовая проверка (1) Тип счета, (2) Статус, (3) Тип квоты, (4) Просрочка по счету, (5) Тип ставки [Пока нет]
        LogicCheckResultEntity logicCheckResultEntity = doCheckLogic(adjustAssetApplyEntity, userAccountInfoDTO,
                DefaultLogicFactory.LogicModel.ACCOUNT_TYPE_FILTER.getCode(),
                DefaultLogicFactory.LogicModel.ACCOUNT_STATUS_FILTER.getCode(),
                DefaultLogicFactory.LogicModel.ACCOUNT_QUOTA_FILTER.getCode(),
                DefaultLogicFactory.LogicModel.ACCOUNT_OVERDUE_FILTER.getCode()
        );
      
        if (!AssetCycleQuotaAlterCodeEnum.E0000.getCode().equals(logicCheckResultEntity.getCode())) {
            log.info("userId={} taskNo={} Проверка правил, фильтрация и перехват. код:{} info:{}", adjustAssetApplyEntity.getUserId(), adjustAssetApplyEntity.getTaskNo(), logicCheckResultEntity.getCode(), logicCheckResultEntity.getInfo());
            throw new AccountRuntimeException(logicCheckResultEntity.getCode(), logicCheckResultEntity.getInfo());
        }
      
        // 3.4 Принять корректировку квоты
        return this.acceptAsset(adjustAssetApplyEntity, userAccountInfoDTO);
    } finally {
        // 3.1 Распределенная блокировка: разблокировать
        this.unlock(lockId);
    }
}

После этой обработки код становится очень понятным.

1. Сначала выполните базовую проверку, запрос данных и оценку.,Затем добавьте блокировку, чтобы один человек не мог применить сверхурочную работу. После,Вызов и обработка механизма правил,Согласно различным требованиям,Разработайте разные правила,И способ использования конфигурации.
2. После того, как все эти вещи обработаны, производится окончательная корректировка.

7. Опыт программирования

• Рефакторинг,Это то, что происходит постоянно,не может накапливатьприезжатьнаконецталант Рефакторинг。Единственный вариант - переделатьизвозможный。
• Фабрика, шаблон и стратегия — эти три шаблона проектирования могут решить 80% проблем сценариев.
• Брат Стандарты кодирования Фу также станут эталоном для партнеров, поэтому Брат Фу будет предъявлять более строгие требования к собственным стандартам.

8. Строительные леса DDD

• строительные леса(Облегченная версия)：https://gitcode.net/KnowledgePlanet/road-map/xfg-frame-archetype-lite(opens new window)
• строительные леса(Стандартное издание)：https://gitcode.net/KnowledgePlanet/road-map/xfg-frame-archetype-std

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

Нет, совсем нет. потому что что Брат Фу Иметь наборАртефакт！

для DDD Построение многомодульного проекта на самом деле является очень трудоемкой задачей, особенно построение распределенных проектов занимает еще больше времени. Однако создание инженерного модуля не требует слишком много времени. В основном время уходит на интеграцию различных распределенных компонентов, в том числе; MySQL, Redis, RocketMQ, Dubbo, shardingjdbc, XXL-JOB. Жду кучу технических рамок. Если вы когда-либо делали что-то подобное, вас обязательно убедит их использование и взаимодействие с различными версиями.

Настройка проекта и среды может занять от 6 до 8 часов! Но сегодня я хочу, чтобы вы сделали это одним щелчком пальцев!

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

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

1. Дисплей эффектов

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

1.1 Инженерная основа

1.2 Индикация окружающей среды

1.3 Управление Redis

1.4 Управление MySql

1.5 Управление MQ

1.6 Управление должностями

2. Введение в структуру

Брат Фу Здесь поставляет 2 комплекта инженерных лесов, один комплект Облегченная версия используется без какого-либо распределенного технологического стека, другая версия — Стандартная. издание полностью использует стек распределенных технологий. потому что что很多小型项глаз并需要依赖太多из Распределенный стек технологий,И облегченное проектирование и разработка могут более эффективно повысить эффективность разработки. так,Читатели могут выбрать платформу, необходимую им для обучения, проверки и производства.

2.1 Облегченная версия

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

• кэш,использовать Гуава. Если есть конкретные сценарии, вы можете добавить Redis использовать。
• Задача,использовать Quartz。
• информация,использовать Spring/Guava заменять.

2.2 Стандартное издание

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

• Dubbo поставлять RPC Интерфейс, Накос как регистрациясередина Сердцеиспользовать。
• Redis поставлятькэш、Замок、данныеиметь дело с Служить。
• SharedingJdbc поставлять Подбаза данных и подтаблица Служить。
• XXL-JOB поставлятьраспределенный Задача Планирование Служить。
• RocketMQ поставлятьасинхронныйинформация Служить。

3. Инструкция по применению

Этот набор строительных лесов использует maven-archetype-plugin использовать Заказ(archetype:create-from-project)руководитьпроектизстроительные лесасоздавать,После создания существующего внесите некоторые изменения в контент.,Окончательная опалубка для строительных лесов.

Когда читатели существуютиспользовать этот набор строительных лесов,Вы можете скачать код проекта локально.,Входитьпроект Внизиз scaffold-lite/std выполнение модуля README.md середина mvn clean install Скриптруководить Установить。Установитьназад Вот и всесуществоватьиспользовать IntelliJ IDEA При создании проекта выберите Maven Создайте и добавьте адрес локального склада для использования. —— Конкретные шаги будут представлены ниже👇🏻.

3.1 Инженерная конструкция

Как показано на картинке, есть два набора. DDD Проекты строительных лесов, под каждым набором проектов есть scaffold модуль. Эта часть в настоящее время соответствует модулю строительных лесов проекта. кроме того docs Есть dev-ops Папка представляет собой установочный пакет среды, который можно запустить напрямую. docker-compose.yml Вы можете установить всю среду сразу.

Читатели, вы также можете прекратить чтение во время чтения scaffold модуль。потому что Кроме этого модуля, остальные - это весь DDD Работает, как только вы впервые ознакомитесь с использованием. После ознакомления с существованием Входить"черный круг" README.md серединаосуществлять mvc clean install Таким образом, вы можете существовать локально maven На складе установлены строительные леса.

3.2 Установка рамы

3.2.1 Установка

• Введите README.md в модуле формирования леса проекта и нажмите, чтобы выполнить чистую установку mvn.

3.2.2 Конфигурация

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

3.2.3 Использование

• Введите Maven Archetype, чтобы создать проект, как показано на рисунке.

3.2.4 Эффект

• Автоматически сгенерируйте проект, после чего вы сможете пройти docs под файлом docker-compose.yml Установитьокружающая среда ииспользовать Понятно。Обратите внимание, что на этой машине установлен Docker.

4. Установка среды

документ：docs/dev-ops/docker-compose.yml

• Mac компьютер Установить Docker После этого вы можете напрямую нажать маленькую зеленую кнопку, чтобы получить доступ ко всем хорошим средам за один шаг.
• Доступ к облачному серверу можно получить через docker-compose -f docker-compose.yml up -dруководить Установить。
• доступ к ресурсам;
  • Центр конфигурации nacos: http://127.0.0.1:8848/nacos - [Аккаунт: nacos Пароль: nacos]
  • Сообщение rocketmq: http://127.0.0.1:8080/#/ - [Аккаунт: администратор Пароль: admin]
  • Планирование задач xxl-job-admin: http://127.0.0.1:9090/xxl-job-admin/ - [Аккаунт: администратор Пароль: 123456]
  • Редис кэша: http://127.0.0.1:8081/
  • База данных MySQL: http://127.0.0.1:8899/ - Войдите в базу данных, строка существования напрямую управляет базой данных.

ЯсуществоватьучаствоватьНа третьем этапе специального тренировочного лагеря Tencent Technology Creation 2023 года будет проводиться конкурс сочинений. Соберите команду, чтобы выиграть приз!