Введение

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

Поскольку основное внимание в этой статье уделяется тому, как перенести DDD в трехуровневую архитектуру MVC, мы сначала дадим краткое введение в концепцию DDD.(细化的领域概念不做过多展开), а затем сделайте предложение по переносу трехуровневой архитектуры MVC на DDD. Если что-то не так, пожалуйста, укажите на это и двигайтесь вперед вместе.

Отдельное спасибо за эту статьюlilpilotЦенные предложения по плану посадки DDD.

Блог серии DDD

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

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

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

2. Что такое ДДД

2.1. Введение в DDD

Я полагаю, что студенты, которые узнали о DDD, слышали официальное введение в Интернете:

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

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

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

Как мы все знаем, талант — самая большая ошибка в системе.

После того, как требования пользователя выдвинуты и претерпели столь много уровней трансформации, особенно после того, как требования НИОКР трансформируются на уровне структуры базы данных, бизнес трансформируется субъективным поведением. Как только границы бизнеса размыты, рассмотрение становится неполным. К кодовой реализации нагромождается большое количество логических дополнений, и ее становится все сложнее поддерживать.Везде if/else, и легендарный ***одинаковый код.

Все, что нужно сделать DDD, это

Устранение информационной асимметрии
Метод проектирования «снизу вверх» в традиционной трехуровневой архитектуре MVC является обратным, бизнес-ориентированным, а бизнес-области разделены сверху вниз.
Разделяйте потребности крупного бизнеса и разделяйте и властвуйте

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

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

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

2.2 Зачем использовать DDD

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

2.3. Введение в терминологию DDD

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

Тактический дизайн: агрегаты, сущности, объекты значений, репозитории, доменные службы, доменные события, модули

2.3.1 Ограниченные контексты и универсальные языки

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

Общий язык — это язык, который может просто, ясно и точно описывать бизнес-значения и правила.

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

域是问题空间，限界上下文是解决空间

2.3.2 Организация контекста и шаблоны интеграции

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

2.3.3. Объекты

Сущности в DDD должны быть уникальными и постоянно изменяться. Это означает, что в течение жизни сущности, как бы она ни менялась, она остается одной и той же сущностью. Уникальность определяется уникальной идентичностью. Изменчивость также отражает состояние и поведение самого объекта.

实体 = 唯一身份标识 + 可变性【状态 + 行为】

2.3.4 Объекты-значения

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

值对象=将一个值用对象的方式进行表述，来表达一个具体的固定不变的概念。

2.3.5. Агрегация

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

我们把一些关联性极强、生命周期一致的实体、值对象放到一个聚合里。

2.3.6 Совокупные корни

Совокупный корневой объект, наиболее представительный объект

2.3.7 Доменные службы

Когда какая-то логика не принадлежит сущности, эту логику можно вынести отдельно и вынести в доменную службу理想的情况是没有领域服务, если доменная служба не используется должным образом, она будет постепенно возвращаться к предыдущей ситуации, когда вся логика находится на уровне службы.

Ситуации, в которых можно использовать доменные службы:

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

2.3.8 Службы приложений

Служба приложений используется для表达用例和用户故事основные средства.

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

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

应用层作为展现层与领域层的桥梁. Уровень представления использует VO (модель представления) для отображения интерфейса и взаимодействует с прикладным уровнем через DTO (объект передачи данных), чтобы достичь цели разделения уровня представления и DO (объекта предметной области).

2.3.9 Фабрика

Ответственность состоит в том, чтобы создать полную совокупность

заводской метод
Заводской класс

Фабрика в модели предметной области

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

Фабричные методы в совокупных корнях

Фабричный метод в совокупном корне выражает концепцию предметной области.
Заводские методы могут обеспечить защиту

Фабрика доменных служб

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

2.3.10 Библиотека ресурсов [Склад]

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

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

2.3.11 Модель событий

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

Событие предметной области = публикация события + хранилище событий + распространение событий + обработка событий.

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

2.4 Обзор архитектуры DDD

2.4.1 Схема архитектуры

Строго многоуровневая архитектура: уровень может быть связан только с нижележащим уровнем.

Свободноуровневая архитектура: позволяет верхнему слою соединяться с любым нижним.

Принцип инверсии зависимости

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

Абстракция не должна зависеть от деталей реализации, детали реализации должны зависеть от интерфейсов.

Проще говоря, это интерфейсно-ориентированное программирование.

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

Сверху вниз

первый уровеньДля уровня взаимодействия с пользователем внешние входные данные, такие как веб-запросы, запросы rpc и сообщения mq, рассматриваются как внешние входные запросы, которые могут изменять внутренние бизнес-данные.

Второй этажДля уровня бизнес-приложений, в отличие от сервиса в MVC, в сервисе хранится большой объем бизнес-логики. Однако при реализации прикладных служб (с функциональными точками в качестве измерения) он отвечает за оркестровку, пересылку, проверку и т. д.

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

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

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

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

2.4.2 Шестиугольная архитектура (порты и адаптеры)

Для каждого внешнего типа существует соответствующий ему адаптер. Внешний интерфейс взаимодействует с внутренним через API прикладного уровня.

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

2.4.3. Разделение ответственности за команды и запросы — CQRS

Метод объекта модифицирует состояние объекта, метод является командой (Command), он не должен возвращать данные, объявленные как void.
Если метод объекта возвращает данные, этот метод является запросом, и состояние объекта не должно изменяться прямым или косвенным образом.
Агрегация имеет только метод Command, а не метод Query.
В репозиториях есть только методы add/save/fromId.
Модель предметной области делится на две части: модель команд (модель записи) и модель запросов (модель чтения).
Клиент и обработчик запросов Клиент: веб-браузер, настольное приложение и т. д. Обработчик запросов: простой компонент, который знает, как выполнять только основные запросы к базе данных, обработчик запросов не сложен и может возвращать DTO или другие сериализованные наборы результатов, на основе настройки о состоянии системы
Модель запроса: денормализованная модель данных, которая не отражает поведение предметной области и используется только для отображения данных.
Агрегация клиентов и командных процессоров — это командная модель Командная модель имеет хорошо продуманные контракты и поведение, а сопоставление команд с соответствующими контрактами — несложная задача.
Модель запроса обновления подписчика событий
Обработка моделей запросов с окончательной согласованностью

2.4.4 Архитектура, управляемая событиями

Руководство и практика посадки:Событийная модель приземления DDD

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

3. Обмен на земле

3.1. Буря событий

EventStorming — это набор методов Workshop (который можно понимать как семинар, аналогичный мозговому штурму). DDD появился более чем на 10 лет раньше, чем EventStorming.Хотя дизайн EventStorming относится к некоторому содержимому DDD, он не предназначен только для DDD.Это независимая система, основанная на совместной работе для восстановления всей картины на основе событий, поэтому как для быстрого анализа сложных бизнес-доменов, метод выполнения моделирования предметной области.

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

Например, в сценарии электронной коммерции процесс покупки автомобиля вызывает шторм событий.

3.2 Распознавание сцен

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

3.3 Разделение модуля пакета

图片2.png

3.4 Инструкции по миграции

3.4.1 Уровень хранения

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

Если взять в качестве примера текущую реверсивную модель, существующая

OrderDO
OrderDAO

Шаблон репозитория можно реализовать постепенно, выполнив следующие шаги:

Создайте класс объекта Order, начальные поля могут быть согласованы с OrderDO
Создайте OrderDataConverter, в основном 2 строки кода можно выполнить через MapStruct.
Напишите модульные тесты, чтобы убедиться, что преобразование между Order и OrderDO на 100% правильно.
Создайте интерфейс и реализацию OrderRepository и убедитесь в правильности OrderRepository посредством модульного тестирования.
Измените место, где используется OrderDO в исходном коде, на Order
Изменены места, где OrderDAO использовался в исходном коде, на OrderRepository.
Обеспечьте согласованность бизнес-логики с помощью модульного тестирования.

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

Экстремальные сторонники DDD требуют, чтобы в репозитории существовало только два метода агрегирования, save и byId. Конечно, это необходимо решать в соответствии с реальным бизнес-сценарием, но рекомендуется сохранять только эти два метода.Для других методов агрегации запросов, необходимых для бизнеса, можно открыть отдельный репозиторий запросов для достижения агрегации запросов и отображения данных страницы разные данные. гарантированные данные增删改入口唯一

3.4.2. Изолировать сторонний адаптер зависимостей

Идея та же, что и в репозитории, в качестве примера возьмем вызов payApi:

Создайте новый пакет адаптера в домене
Создайте новый интерфейс PayAdapter
Определите реализацию адаптера в инфраструктуре, преобразуйте внутреннюю модель и внешнюю модель, вызовите платный интерфейс и верните внутреннюю модель dto.
Измените место, где rpc вызывается в исходном бизнесе, на адаптер
Одиночный тест сравнивает rpc и адаптер для обеспечения правильности

3.4.3 Компоненты технологии экстракции

Это также соответствует идее шестиугольной архитектуры.Технические компоненты, такие как mqProducer и JsonUtil, определены в домене и реализованы в инфраструктуре.Этапы замены аналогичны шагам адаптера.

3.4.4 Приложение модуляризации бизнес-процессов

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

3.4.5 Явный параметр CQRS

Проект цепочки возможностей, определение команды, пакет запроса, отражение команды и запроса через цепочку возможностей, включая наследование CommandService, QueryService, Po, наследующее CommandPo, QueryPo

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

3.4.6 Домен стратегического дизайна

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

Замените метод с бизнес-значением, который изначально назывался репозиторием, на save, и одновременно удалите метод с бизнес-значением. В это время вы можете рассмотреть возможность замены mybatis на jpa. Здесь это зависит от выбора каждого субдомена. Если вы используйте jpa, слой dao можно устранить. До сих пор большинство классов в исходном бизнесе были перенесены.

4. Вопросы, которые могут возникнуть в процессе миграции

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

1.领域服务与应用服务的实际应用场景区别

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

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

2.聚合根定义的业务边界是什么？

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

3.一个command修改一个聚合时，会关联修改到别的关联表，这个关联表算不算聚合

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

4.应用服务层如果调用rpc是否必须使用adapter

Да, его необходимо использовать для защиты от влияния внешних зависимостей на текущую бизнес-логику. Представьте, что вам сейчас нужно вызвать интерфейс rpc, возвращается 100 полей, и вы хотите взять из них 50. Через некоторое время вызывающая сторона изменяет возврат логики интерфейса, и данные включаются в сущность. И вы вызываете этот интерфейс во многих местах, и изменения будут большими. Но если есть уровень адаптера, вам нужно только определить структуру данных, необходимую для вашего собственного бизнеса, а остальную часть бизнеса не нужно рассматривать.Полный адаптер новичка может загружать данные, которые вы хотите, из rpc.

5.聚合根内部逻辑无法单独处理时，放到领域服务内的话，是否可以调用其他聚合根的领域服务或者应用服务，加入业务强绑定形式，聚合根内部如果需要调用service服务或者仓储时如何做。

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

6.事件通知模式，比如是强绑定形式的，是否还是此种方式，还是与本聚合根无关的逻辑均走事件通知

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

7.聚合根，PO,DTO,VO的限界

po — это однозначное соответствие структуры таблицы базы данных.

dto — это носитель данных, анемичная модель, которая только загружает данные.

vo — это пакет, когда структура dto не соответствует требованиям внешнего интерфейса.

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

8.查询逻辑单独开设一个repository，还是可以在聚合根的仓储中，划分的依据是什么

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

9.返回的结果数据为多个接口组成，是否在应用服务层直接组合

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

10.save方法做完delete，insert，update所有方法吗？

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

11.查询逻辑如果涉及到修改聚合根怎么处理

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

12.逻辑处理的service放置在何处

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

5. Резюме

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

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

демо демо:DDD-demo

Блогер о многоуровневой микросервисной архитектуре MVC также дал некоторые спецификации дизайна в предыдущей статье, Если вам интересно, вы можете пойти и посмотреть:

1.Прочитав это, вы станете архитектором

2.Пожалуйста, прекратите писать код реликвии