《小型支付商城系统》四色建模设计实战：从用例图到 DDD 领域拆分的研发设计全流程

文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载导读本文基于《小型支付商城系统》实战项目的研发设计阶段完整讲解一套需求评审 → 用例图 → 四色建模领域拆分→ UML 流程图 → 改动点的研发设计流程。这套流程正是 DDD领域驱动设计工程落地前最关键的战略设计环节读者学完后可以掌握如何从产品 PRD 中提炼用户行为并绘制用例图、如何通过四色建模将业务需求拆分为清晰的领域模型、以及如何用设计产物直接指导后续的 MVC / DDD 双套工程编码实现。一、本章诉求先评审需求再做研发设计在公司实际做项目的流程中任何一个需求都不是研发直接上手写代码的。它通常先由产品拉一个评审会对本地需求的 PRD 进行评审参与方包括产品、研发前后端、测试会议时长一般在30分钟 ~ 2小时。评审完成后研发会对需求进行分工较大型的项目会有几个研发同时介入。之后每个研发进入设计阶段设计内容会包括新项目的工程框架搭建方案技术栈选择需求的模型设计DDD功能的流程MVC实现要实现和改动点说明等。本节正是按照这样的过程对支付商城需求进行研发设计最终交付四类设计产物用户用例图、四色建模领域拆分、UML 流程图、改动点。有了这些产物就可以直接指导研发开发了。一个特别值得注意的设计决策是本项目会搭建 MVC、DDD 双套工程而四色建模主要给 DDD 工程使用。也就是说同一套支付商城需求会分别用 MVC 架构与 DDD 架构各实现一遍方便学习者对照两种架构在对象设计、思维方式、编码结构上的差异。MVC 工程偏向流程编排DDD 工程则依赖四色建模先完成领域拆分再逐领域实现。二、需求回顾这个支付商城要做什么在进入设计之前先回顾本节所服务的需求背景详见 第1节小型支付商城需求设计市场运营根据公司发展诉求为公司产品电脑、键盘等提供一个简单小巧的自有在线商城售卖公司产品。根据市场调研有 55% 的用户非常有意愿通过厂家直售的方式购买商品这样即可减少冗余渠道线直接让利给消费者。交互主流程用户通过小型电商查看购买商品 → 点击购买时校验登录 → 微信扫码登录 → 下单并跳转支付宝收银台完成支付。两个核心对接点登录通过微信公众号扫码登录降低用户注册登录成本、支付对接支付宝交易通过支付宝完成支付。同时从 项目总览 可以看到这套项目还覆盖了商品支付掉单如何处理、相关的任务补偿怎么操作等真实生产核心问题整体是一条包含前后端与 DevOps 的完整实战链路。三、画用例图系统交互蓝图的起点研发可以根据产品 PRD 提供的业务 UI 和流程分析出用户会有的行为再根据行为画出用户用例图。用例图是四色建模乃至整个 DDD 设计流程的起点——因为 DDD 的建模过程是以一个用户为起点通过行为命令发起行为动作串联整个业务而这个用户起点最初就来自用例图的分析。3.1 什么是用例图用例图英语use case diagram是用户与系统交互的最简表示形式展现了用户和与他相关的用例之间的关系。通过用例图人们可以获知系统不同种类的用户和用例。用例图也经常和其他图表配合使用。用例图也可以等同于是用户故事英语User story软件开发和项目管理中的常用术语主旨是以日常语言或商务用语撰写句子是一段简单的功能表述。以客户或使用者的观点撰写下有价值的功能、引导、框架来与使用者进行互动进而推动工作进程。它可以被认为是一种规格文件但更精确而言它代表客户的需求与方向。以该用户故事来反应对象在组织内的其工作职责、范围、需要进行的任务等。用户故事在敏捷开发方法中用来定义系统需要提供的功能和实现需求管理。尽管用例本身会涉及大量细节和各种可能性用例图却能提纲挈领地让人了解系统概况。它为系统做什么提供了简化了的图形表示因此被誉为搭建系统的蓝图。3.2 支付商城的用例图怎么画结合支付商城的需求用户顾客在系统中的核心行为可以提炼为一组用例例如用例用户故事用户行为描述浏览商品用户进入商城首页查看公司自营商品列表与详情购买商品触发登录校验用户点击购买系统校验登录态未登录则引导扫码登录微信扫码登录用户通过微信公众号扫码完成身份认证降低注册登录成本创建订单登录后的用户提交商品下单请求系统创建订单发起支付用户确认订单后跳转支付宝收银台完成支付接收支付回调支付宝支付成功后回调系统系统更新订单支付状态查看订单/退单用户查看订单状态处理支付掉单后的补偿等场景这组用例就是对系统做什么的简化图形表示。之后四色建模的所有领域事件与决策命令都从这组用例中推导而来。四、四色建模DDD 领域拆分的核心实践四色建模风暴事件是整个 DDD 软件设计方法中用于拆分界限上下文的非常重要的实践手段。通过建模过程可以快速识别业务领域中的关键事件和核心流程也是在这个过程中设计出领域对象的为后面详细设计和代码开发做指导。你可以把整个过程理解为为工程开发提供面向对象设计涵盖领域拆分、界限串联、功能聚合。所以相比Service 数据模型的贫血开发方式DDD 前期需要付出更多的设计成本但对于软件的长周期迭代这样的好处是非常大的。这一建模方法的完整理论说明可参阅仓库中的 第1-2节 DDD 建模方法。4.1 建模目的为工程开发提供蓝图工程建模的目的是为了在做工程开发时提供指导方案就像一栋大楼的设计蓝图也像一个超市中会有不同品类的货架需要提前规划好。工程开发时所需的各类核心内容都会在建模中体现例如分几个包、有哪些核心对象、要串联什么流程、有哪些核心业务要实现、过程中与外部服务的交互。为了达成讨论的共识而不是每个人都有一套自己的标准和词汇会使用 DDD 提供的专门建模方法和名词进行统一设计。此外因为 DDD 的统一建模语言不涉及技术编码、具有通用性所以可以在建模过程让产品、研发、测试、架构师等人员一起参与讨论例如领域、领域模型实体、聚合、值对象、领域服务、端口适配器、仓储、界限上下文、领域编排等名词。4.2 怎么建模六种颜色的语义DDD 的建模过程以用户为起点通过行为命令发起行为动作串联整个业务。在使用 DDD 的标准对系统建模前参与人员要先了解 DDD 的操作手段这样才能让产品、研发、测试、运营等了解业务的伙伴都能在同一个语言下完成系统建模。四色建模指导图通过寻找领域事件 → 发起事件命令 → 完成领域事件的过程完成 DDD 工程建模。模型中的六种颜色分别承载不同的语义颜色角色语义说明蓝色决策命令用户发起的行为动作如开始签到、开始抽奖、查看额度等黄色领域事件过去时态描述如签到完成、抽奖完成、奖品发放完成。阐述的是这个领域要完成的终态粉色外部系统你的系统需要调用外部的接口才能完成的流程红色业务流程用于串联决策命令到领域事件所实现的业务流程。一些简单的场景则直接由决策命令到领域事件即可绿色只读模型做一些读取数据的动作没有写库的操作棕色领域对象每个决策命令的发起都含有一个对应的领域对象这六种颜色共同组成了领域拆分的表达语言蓝色与棕色刻画了用户做什么、带着什么对象做黄色刻画了做成了什么事终态粉色刻画了需要外部系统协作的点红色刻画了流程怎么串联绿色刻画了哪些环节只读不写。4.3 支付商城的四色建模落地将六色语义套用到支付商城需求上可以拆出如下几个典型的界限上下文与建模要素领域场景决策命令蓝领域对象棕领域事件黄外部系统粉用户登录发起微信扫码登录登录 ticket 对象登录完成微信公众号平台商品下单点击商品下单商品/订单创建入参对象订单创建完成本系统内部流程对接支付创建支付宝支付单支付单领域对象支付单创建完成支付宝沙箱/开放平台支付回调接收支付结果通知回调报文对象支付成功、订单状态更新完成支付宝每个决策命令的发起都含有一个对应的领域对象——这正是后面 DDD 工程中入参领域对象的设计源头。而黄色的领域事件登录完成、订单创建完成、支付完成就是各领域要完成的终态后续工程实现时一个领域功能对应一个决策命令与一个领域事件。五、UML 流程图串联领域间的时序关系用例图回答了系统做什么四色建模回答了领域怎么拆而UML 流程图则回答流程怎么走——它用于串联决策命令到领域事件之间、以及多个领域之间的调用关系。在支付商城场景中UML 流程图需要表达的核心链路是用户在小商城页面发起登录请求系统生成微信扫码登录 ticket引导用户扫码用户扫码授权后系统完成鉴权并建立登录态用户选择商品点击下单系统校验登录态后创建订单对应 DDD 工程中的商品下单领域系统基于订单创建支付宝支付单跳转支付宝收银台对应对接支付领域用户在支付宝完成支付支付宝回调系统系统更新订单支付状态对应支付回调领域对支付掉单等异常场景由任务补偿机制兜底处理。这条链路中的每一步在后续工程实现中都有对应章节DDD 部分依次为 DDD 重构微信公众号鉴权、DDD 重构登录功能实现、DDD 重构商品下单、DDD 重构对接支付、DDD 重构支付回调MVC 部分则有对应的 MVC 功能实现各节。六、改动点说明改动点说明是研发设计中要实现和改动点说明的落点用于回答两个问题复用与新增哪些能力是平台或既有工程已经具备、可以直接复用的哪些是需要本次新开发的例如微信扫码登录、支付宝交易对接、订单创建、支付回调处理影响范围本次需求会触及哪些工程模块、哪些接口、哪些库表涉及的表结构设计可参考 第3节支付订单场景表设计。在支付商城项目中改动点设计上的一个关键决策就是前面提到的双套工程一套以 MVC 三层结构实现面向流程一套以 DDD 分层结构实现面向领域两者共享同一套需求与库表设计。这样既明确了每个功能在两种架构下的承载位置也让改动边界清晰可控。七、从设计到代码四色建模如何指导 DDD 工程落地四色建模的产物不是停留在纸面上的图而是要直接指导后续编码的。仓库的 DDD 实现章节多次回指本节设计例如 DDD 重构商品下单 中给出的落地对照相对于 MVC 工程的设计DDD 的每个领域就是独立的空间它会仔细考虑请求方法的出入参对象而这些对象叫做领域对象。在整个实现过程每一个领域的功能我们可以想象为一个人拿着一把钥匙开锁到进屋。那么这里的一个人是用户、一把钥匙是入参领域对象、开锁是决策命令完成开锁进屋是做完了一件事的领域事件。这个过程就是四色建模中的战略设计过程。这个比喻精确对应了四色建模的核心要素用户 行为发起者入参领域对象棕色 那把钥匙是决策命令的载体决策命令蓝色 开锁这个动作领域事件黄色 完成开锁进屋即该领域要达成的终态。以商品下单领域为例用户通过购物车创建订单到支付其决策命令是创建订单领域对象是下单入参对象商品、用户、数量等信息领域事件是订单创建完成随后进入对接支付领域决策命令是创建支付宝支付单领域事件是支付单创建完成。可以看到四色建模中定义的决策命令与领域事件直接决定了 DDD 工程中每个领域服务的入参与出参设计。同样地DDD 重构微信公众号鉴权 也明确指出工程四色建模是拆分领域功能界限上下文的战略设计知识而具体的战术设计实体、值对象、仓储、应用服务等则在后续实现章节中逐领域落地。这也印证了四色建模在 DDD 落地中的承上启下作用——它是连接需求分析与工程实现的桥梁。八、总结本节完成的研发设计工作可以浓缩为一条清晰的方法论链路评审需求产品、研发、测试共同评审 PRD明确需求范围与验收预期画用例图以用户视角提炼行为动作形成系统做什么的蓝图四色建模用蓝决策命令、黄领域事件、粉外部系统、红业务流程、绿只读模型、棕领域对象六种颜色完成 DDD 领域拆分为 DDD 工程划定界限上下文画 UML 流程图串联登录、下单、支付、回调等核心流程的时序关系列改动点明确复用与新增、影响范围让设计可落地、可评估。对于学习 DDD 的开发者而言这套流程的价值在于它把抽象的领域驱动设计转化为一套可操作的、全员共识的建模语言并且后续每一节 DDD 代码实现都能在设计中找到依据。对照着 MVC 工程与 DDD 工程两套实现去学习可以直观体会面向流程与面向领域两种设计思维的差异——这正是本项目的设计初衷。赞分享文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载相关推荐《小型支付商城系统》DDD 重构支付回调从 MVC 拆分到领域驱动设计的支付闭环处理《小型支付商城系统》DDD 重构支付回调从 MVC 拆分到领域驱动设计的支付闭环处理 支付回调是支付流程的收尾环节也是面试官验证你是否真正对接过支付而非文档教程后端DDD 四色建模方法实战以《小型支付商城系统》为案例拆解事件风暴建模全过程DDD 四色建模方法实战以《小型支付商城系统》为案例拆解事件风暴建模全过程 四色建模又称事件风暴Event Storming是 DDD 领域驱动设计中最文档教程后端小型支付商城 DDD 重构实战以四色建模驱动商品下单领域实现小型支付商城 DDD 重构实战以四色建模驱动商品下单领域实现 本文基于《小型支付商城系统》第 3 4 节《DDD 重构商品下单》展开讲解如何把 MVC 工文档教程后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考