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

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

Всем привет, я Брат Фу, мастер технического УП.

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

Вы можете понять весь процесс как,Обеспечить объектно-ориентированное проектирование для инженерных разработок,Разделение поля обложки, Конкатенация; границ、Функцияполимеризация。Так что по сравнению сService + данные МодельКак развивается анемия,DDD На ранней стадии требуются большие затраты на проектирование, но для долгосрочных итераций программного обеспечения выгоды очень велики.

1. Цель моделирования

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

Таким образом, чтобы достичь консенсуса для обсуждения, не у всех есть набор стандартов и словарный запас. Так что буду использовать DDD Предоставьте специализированные методы моделирования и существительные для унифицированного дизайна, кроме того, потому что DDD Единый язык моделирования,Никакого технического кодирования не требуется,Также универсальный,так оксуществовать Моделированиепроцесс делает продукт、НИОКР、тест、В обсуждении приняли участие Архитектор и другие люди. Такие как;、Модель домена (сущность、полимеризация、ценный объект)、Доменные услуги、адаптер порта、складирование、ограниченный контекст、Расположение домена и другие условия。Это существование было объяснено в предыдущем разделе.

2. Как моделировать

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

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

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

• Синий — команда принятия решения, представляющая собой поведенческое действие, инициируемое пользователем, например, начало регистрации, начало лотереи, проверка квоты и т. д.
• желтый - доменное событие, описание в прошедшем времени. Например; вход завершен.、Лотерея завершена、Раздача призов завершена. То, что он описывает, является окончательным состоянием, которое должно быть завершено в этом поле.
• розовый — внешняя система, например, вашей системе необходимо вызвать внешний интерфейс для завершения процесса.
• красный – бизнес-процесс,Используется для объединения команд принятия решений в события доменов.,Реализован бизнес-процесс. Для некоторых простых сценариев достаточно напрямую отправить команду принятия решения на поле события.
• зеленый - Только чтение Модель,Выполните некоторые действия для чтения данных,Операции по записи библиотеки нет.
• Коричневый — объект домена. Каждая инициированная команда принятия решения содержит соответствующий объект домена.

👩🏻‍🏫Постучите по доске Итак, вот схематическая диаграмма в левом нижнем углу. Это пользователь, который с помощью команды политики использует объекты домена, выполняет два события домена посредством бизнес-процессов и вызывает один процесс внешнего интерфейса. Мы ищем эти узлы на протяжении всего процесса моделирования DDD.

3. Пример супермаркета

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

• Мысли в его голове были инструкциями, данными его женой. Мы можем понимать это как команду принятия решений. Актер пришел в супермаркет с заказом.
• Корзина покупок — это сущность,Сущность, которую необходимо заполнить данными. преступник,с сущностью,Зайдите в супермаркет и купите продукты с разных полок.,Добавить в корзину. Закупка товаров – это бизнес-процесс,Полная корзина покупок для выездного мероприятия. Это окончательное состояние,Выполняйте задания, поставленные женой. И сигарета в моей руке,Это еще одно полевое событие. То есть,Одно поведенческое действие может заполнить несколько полей.
• После заключительного шоппинга возьмите такси домой. Это следующий полевой процесс. Соединяя все поле от выхода на улицу, поездки в метро, ​​входа в супермаркет, покупки и поездки на такси домой, это и есть оркестровка поля.

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

4. Бизнес-кейс

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

1. Привлекательность продукта

Как показано на картинке,Это сложный сценарий маркетинговой лотереи с требованиями к игровому процессу.,Крышка Понятно；Конфигурация активности、Войти&награда、активный аккаунт、Стратегия лотереи «Цепочка ответственности + Дерево правил»、Инвентарные вычеты、Пошаговая лотерея после N розыгрышейждать。Столкнувшись с такой сложностьюсистема,Отлично подходит для использования DDD Приземлился.

Анализировать потребности;

1. Общие вероятности суммируются, сумма равна 1 или рассчитывается как балл, диапазон вероятностей составляет тысячные доли.
2. Лотерея — это количество бесплатных розыгрышей + пользователь тратит личные баллы на розыгрыш лотереи.
3. Лотерейная деятельность может распределять количество розыгрышей среди пользователей и выдавать их, щелкнув для входа в систему.
4. Это действие расширяет настройку управления потреблением пользовательских запасов и предоставляет отдельные таблицы для настройки различных типов запасов, общего запаса, доступного пользователям, и ежедневного запаса, доступного пользователям.
5. Некоторые правила лотереи необходимо разблокировать после n розыгрышей, прежде чем у вас появится возможность сделать розыгрыш.
6. Завершение лотереи увеличивает рекорд (значение удачи/стоимость очков/количество розыгрышей), позволяя пользователям получать призы.
7. Призовая стыковка, собственные баллы, внутренняя система призов
8. Вам будут даны случайные очки.
9. Пользователям черного списка будут предоставлены фиксированные призы в лотерее.

2. Диаграмма вариантов использования

Рисовать диаграммы вариантов использования системы на основе бизнес-требований;

• диаграмма вариантов использования（Английский：use case диаграмма) — это простейшее представление взаимодействия пользователя с системой, показывающее отношения между пользователем и связанными с ним вариантами использования. По диаграмме вариантов использования, можно узнать о системе различных типов пользователей и вариантах использования. диаграмма вариантов использование также часто используется в сочетании с другими диаграммами.
• диаграмма вариантов использования, также можно приравнять к пользовательским историям (английский: User история) (общий термин в разработке программного обеспечения и управлении проектами),Суть в том, чтобы писать предложения на повседневном языке или в деловых терминах.,Это простое функциональное утверждение. Напишите ценные функции, рекомендации и структуры с точки зрения клиентов или пользователей для взаимодействия с пользователями.,А затем продвигать рабочий процесс. Можно рассматривать как документ спецификации.,Но точнее,Он представляет потребности и направления клиентов.。Отразите объект с помощью этой пользовательской историисуществоватьсвои должностные обязанности в организации、объем、Задачи, которые необходимо выполнить и т. д. Пользовательские истории используются в методах гибкой разработки для определения функций, которые система должна обеспечивать, и реализовывать управление требованиями.
• Хотя сами варианты использования включают в себя много деталей и возможностей.,Диаграмма вариантов использования может дать людям общее представление о системе в общих чертах. Он обеспечивает упрощенное графическое представление того, «что делает система».,Поэтому он известен как «проект построения системы».

3. Найдите события в домене

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

• По продукту PRD документ,Проведите совещание вместе, чтобы разобраться, какие области есть. Фактически, в большинстве областей событий можно подумать о,Просто некоторые мелкие сцены и возможные события, которые могут произойти в будущем, могут быть не полностью освещены. Значит нужно сдать продукт, протестировать и Архитектора команды.,Обсудите вместе.
• Как и вся большая маркетинговая лотерея, включает в себя Как показано на событие указано на картинке. существуют перечислить этот этап,Вы используете формат существования. Вы также можете приготовить желтые стикеры для всех.,Когда вам придет в голову одна мысль, напишите ее на доске.,Просто закончи это полностью。—— В настоящем DDD стикеры также прикрепляются к доске, поэтому для их различения используются разные цвета.

4. Определите роли и объекты домена

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

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

5. Определите границы домена

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

5.1 Круговые зоны

5.2 Границы домена

• На этом этапе мы можем получить весь проект DDD изграница домен разделен. Далее следует детальное проектирование и технологическое проектирование конкретных объектов по каждому направлению.