UML 建模总览

UML（Unified Modeling Language，统一建模语言）是一套用于表达软件结构和行为的图形语言。它的作用不是替代代码，也不是把所有设计都画成复杂图纸，而是在概念、模块、对象关系、调用流程和状态变化不容易用文字说明时，提供一套大家能共同阅读的表达方式。

在架构设计中，UML 最有价值的场景有三类。第一类是解释结构，例如一个订单聚合包含哪些对象、服务之间依赖怎样排列；第二类是解释流程，例如支付完成后订单、库存、履约之间怎样协作；第三类是解释状态，例如订单从待支付到已发货再到已完成，中间哪些动作可以触发状态变化。

常用图的分工

类图适合表达静态结构。它能展示类、接口、属性、方法以及对象之间的关系，常用于说明领域模型、设计模式、模块内部对象结构。类图画得好，读者能看出谁拥有谁、谁依赖谁、谁继承谁、谁实现接口。

时序图适合表达对象之间按时间发生的交互。一次下单支付流程中，用户、订单应用服务、订单聚合、支付网关、事件发布器之间的调用顺序，用时序图会比长段文字清楚。它尤其适合定位“谁先调用谁”“失败发生在哪一步”“同步调用和异步事件在哪里分界”。

活动图适合表达流程分支。审批、结算、发货、退款这类有条件判断和多条路径的业务，用活动图可以把正常路径、异常路径、并行处理和结束条件画清楚。它更像流程图，但语义更标准。

状态机图适合表达对象生命周期。订单、工单、保单、任务这些对象的状态较多时，只写状态枚举很容易漏掉非法流转。状态机图能清楚表达“什么事件可以把对象从一个状态推到另一个状态”。

用例图适合表达系统边界和参与者目标。它不适合承载细节设计，更适合需求早期说明某类用户能完成哪些业务动作。组件图、部署图更偏架构层，用来说明模块、服务、节点、运行环境之间的关系。

选择图示的方式

画 UML 时应先问要解决哪类沟通问题。要说明领域对象关系，用类图；要说明一次请求的调用顺序，用时序图；要说明业务流程分支，用活动图；要说明状态变化，用状态机图；要说明系统对外提供的能力，用用例图；要说明服务和部署关系，用组件图或部署图。

图不宜追求全量。一个图只表达一个层次的问题：领域模型图不混入数据库表结构，时序图不塞进所有异常分支，部署图不展开每个类。图越想包罗万象，越难维护，也越难阅读。

和 DDD 的关系

DDD 提供建模思想，UML 提供表达工具。限界上下文可以用上下文映射图表达，聚合内部结构可以用类图表达，领域事件协作可以用时序图表达，订单生命周期可以用状态机图表达。两者并不绑定，但在复杂业务系统中经常配合使用。

例如订单上下文中，类图可以说明 Order、OrderLine、Money 的关系；时序图可以说明“支付订单”这个用例怎样调用支付网关并发布 OrderPaid；状态机图可以说明订单从 Created 到 Paid、Shipped、Completed、Cancelled 的合法流转。读者不必从几十页文字里拼关系，图和正文可以互相校验。

绘图检查

一张可发布的 UML 图应能独立解释核心关系。类图里的箭头要能区分依赖、关联、聚合、组合、继承和实现；时序图里的调用顺序要和真实代码或目标设计一致；活动图的分支条件要能读出业务判断；状态机图不能只列状态，还要写明触发事件。

如果一张图需要大量口头补充才能理解，说明图中层次混杂、命名不清或关系符号使用随意。此时应先缩小范围，只保留当前段落真正要解释的结构或流程。