Введение

Всем привет. Я открыл свой публичный номер на выходных:柏炎大叔. Серия статей выйдет одновременно с Наггетсами, вы можете добавить подписку и получать мои твиты как можно скорее.

Я также создал группу WeChat DDD, так как QR-код нельзя разместить в статье, вы можете добавить меня в WeChat.baiyan_lou, Обратите внимание на обмен DDD, я втяну вас в группу, добро пожаловать на обмен и вместе добивайтесь прогресса.

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

Эта статья расскажет вам о

• Почему мы используем DDD?
• Какая система подходит для DDD?
• Как сделать DDD-код и зачем это делать?

Вы можете прочитать эту статью напрямую, но я рекомендую сначала прочитать ее:Одна статья приведет вас к земле DDD, если у вас уже есть понимание и знание DDD, прочтите его напрямую.

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

Блог серии DDD

1. Одна статья приведет вас к земле DDD
2. Событийная модель приземления DDD
3. Складирование десанта DDD
4. Многоуровневая архитектура лендинга DDD

Мой первый буклет Nuggets«Углубленный ДДД»Он уже онлайн в Наггетс, приглашаем всех попробовать~

2. Почему мы используем DDD

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

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

Ближе к дому я считаю, что в основном 99% читателей Java-разработок, независимо от того, являетесь ли вы специалистом в области бухгалтерского учета или специалистом по межспециальным специальностям, когда вы впервые изучаете Spring или Springboot, слои кода, с которыми вы сталкиваетесь, — это MVC.

Это показывает, что у MVC есть свои уникальные преимущества:

• Разработчики могут сосредоточиться только на одном из слоев всей структуры;
• Старый уровень реализации легко заменить новой реализацией;
• можно уменьшитьЭтажиЭтажзависимости между;
• В пользу стандартизации;
• выгодно каждомуЭтажПовторное использование логики.

Но так ли это на самом деле? По мере повторения функций вашей системы бизнес-логика становится все более и более сложной. Среди трех уровней MVC уровень V используется в качестве носителя данных, а уровень C используется в качестве уровня логической маршрутизации.На уровне M (уровень модели) накапливается большой объем кода. Класс обслуживания имеет сотни или тысячи строк, или даже десятки тысяч строк со сложной логикой вложенности и неясной основной бизнес-логикой. Сервис чуть светлее, код как клей, логика выполнения БД и управление, возвращаемое на фронтенд, склеены между собой, первичное и вторичное непонятно.

Когда вы смотрите на свой проект, там много классов и кода, и вы даже не знаете, как модифицировать код, как «дерьмовая гора».

В чем причина, в конце концов?

service承载了它这个年纪不该承受的业务逻辑。

Например:Вы отвечаете за построение проекта от 0 до 1, а дальше бизнес становится все лучше и лучше, и набираются новые исследования и разработки. Новый R&D разработан с вами.Логические методы сервисного слоя похожи, но не идентичны.Чтобы не лениться, я скопировал ваш код и изменил небольшой кусок логики. На данный момент размер вашего кода в основном умножается на 2. Точно так же, если есть другой человек, размер вашего кода может быть умножен на 4. Однако существует множество POJO как носителей данных, и они пусты.Вы хотите вставить логику, но обнаруживаете, что нет возможности начать. POJO贫血模型В ловушке порочного круга.

Так почему же DDD может решить вышеуказанные проблемы?

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

В значениях DDD любой бизнес является отражением ответственности модели бизнес-домена. Домен A будет выполнять действия только в домене A. Если домен A хочет модифицировать домен B, ему необходимо найти посредника (антикоррозийный слой) для завершения операции в домене B. Я хочу выполнить длинное действие бизнес-логики.После разделения бизнес-границы передать ее оркестратору (службе приложений) бизнес-службы для организации бизнес-модели (агрегации) для завершения логики.

Таким образом, каждая служба (домен) будет выполнять действия только в пределах своих бизнес-границ и определять реализацию требований минимальным и детальным образом. ранее пустой贫血模型превратился в充血模型. В сервисе с длительным принципом код упаковки носителя данных, не связанный с бизнес-логикой, такой как установка и получение значений, будет удален, а ввод应用服务Слой, ваш код — это ваша бизнес-логика. Четкая логика и высокая ремонтопригодность!

3. Какая система подходит для DDD

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

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

Так что же это за система, которая не подходит для DDD?

Для малых и средних систем объем бизнеса невелик, а функция едина.Безусловно, лучше всего выбрать архитектуру mvc.

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

Наоборот, какая система адаптируется к DDD?

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

В конце концов:

Если вы не знаете DDD или ваши системные функции просты, выберите MVC.

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

В других случаях следует рассматривать DDD как подходящее.

4. Как делать DDD-код и зачем это делать

4.1 Классическая многослойность

Уровень приложения добавляется между уровнем пользовательского интерфейса и уровнем бизнес-логики, уровень бизнес-логики заменяется на уровень домена, а уровень доступа к данным заменяется на уровень инфраструктуры, преодолевая прежние ограничения доступа к базе данных. При изначальном мышлении зависимости передаются сверху вниз. Пользовательский интерфейс зависит от прикладного уровня, а прикладной уровень зависит от уровня предметной области и уровня инфраструктуры. Чем ниже уровень, тем дальше от бизнеса и более общий; из соображений повторного использования общие функции будут разделены на фреймворки или платформы, а низкоуровневый (уровень инфраструктуры) будет вызывать и зависеть от этих фреймворков, что приводит к тому, что бизнес-объекты (уровень предметной области) полагаются на внешние платформы или рамки.

4.2 Уровни инверсии зависимостей

Чтобы преодолеть зависимость бизнес-домена, поднимается инфраструктура и определяется интерфейс, когда доменная служба пересекается с инфраструктурой.（灰度接口）, пусть инфраструктура реализует соответствующий интерфейс. Сам интерфейс находится между службами приложений и службами домена и существует для очистки уровня домена.

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

4.3. Многоуровневая цепочка вызовов запросов DDD

4.3.1. Добавления, исключения и изменения

1. Уровень взаимодействия с пользователем инициирует запрос

2. Уровень службы приложений организует бизнес-логику [только расположение методов, без обработки какой-либо логики]

3. Если логика оркестровки зависит от стороннего RPC, определите адаптер, и поле сторонней службы повлияет на службу.

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

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

6. После завершения логической обработки вызывается метод агрегации репозитория.

4.3.2 Запрос

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

5. Резюме

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

6. Отдельное спасибо

lilpilot

7. Свяжитесь со мной

Если есть какие-то неточности в тексте, поправьте меня, текст писать непросто, ставьте лайк, хорошо~

Диндин: louyanfeng25

WeChat: baiyan_lou

Общественный номер: дядя Бай Ян