描述类、属性和继承关系,拿一张 UML 类图。
UML 类图:抽象类 Shape 含 area() 方法,子类 Circle(radius: double)、Rectangle(width, height)、Triangle(base, height),各自 override area()。
Try it →员工类层级:Person(name, email, phone)。Employee 继承 Person(employeeId, salary, hireDate)。Manager 继承 Employee(directReports 列表)。Contractor 继承 Person(contractEnd, hourlyRate)。显示可见性标记和 getter。
Try it →电商领域模型:Customer 有多个 Order。Order 有多个 LineItem。LineItem 引用 Product 含 unitPrice 和 quantity。Product 有 category、sku、price。显示关联的基数和关键方法。
Try it →支付处理采用策略模式:PaymentProcessor 使用 PaymentStrategy 接口。具体策略:StripeStrategy、PayPalStrategy、CryptoStrategy。每个实现 charge(amount) 和 refund(txId)。显示接口实现和组合关系。
Try it →User、Order、Payment、Invoice —— 业务里的那些名词。字段、方法、彼此的关系都在类图上,新人看一眼就知道这个系统在管什么。
领域驱动设计的产出本来就是类图。聚合根、实体、值对象,以及它们之间确切的关系 —— 类图本身就是规范。
发 1.0 之前先把公开出去的 API 画成类图。别人查文档会先看这张图,搞清楚你暴露了什么,比只写注释清楚。
抽这个方法、挪那个字段、把三个类合成一个。前后两张类图一摆,评审的人一眼看到哪里是破坏性改动。
工厂、策略、观察者、访问者,每个经典模式都有固定的类图形状。方案里放一张,看的人不用读完就知道你在用哪个。
一句话 prompt 能把你提到的每个名词都变成一个框,真正会猜错的是箭头:继承还是接口实现、组合还是聚合,在中文描述里长得一模一样。对话模式只就那根会改变设计的箭头问一句,剩下的直接画,画完再把它替你定的箭头一条条列出来。下面这张图是一个 SaaS 的对外通知服务,起点是一句故意含糊的话。
五句回答换来一张每个箭头都有出处的类图:..|> 是渠道契约,*-- 是随通知一起销毁的投递记录,o-- 是活得比 dispatcher 久的渠道。一次性 prompt 也会给你这三个箭头,只是不会告诉你它凭什么这么选 —— 而一条画错的 *--,读起来是一个你代码里根本不存在的生命周期承诺。
类图讲的是代码的结构:有哪些类型、每个类型有什么字段和方法、类型之间靠继承、组合还是关联连起来。
三个常用场合:新人文档里说明领域模型怎么组织;技术方案里提一套新的类层次或者一次重构;面试白板上快速把设计画出来。它也是写设计模式最省事的方式 —— 工厂、策略、观察者、访问者各有一套固定画法,看的人一眼就认出来。
Mermaid 的 classDiagram 支持常用的 UML 记号:可见性(`+` 公开、`-` 私有、`#` 受保护、`~` 包内)、抽象类和抽象方法、`<<interface>>` 标注、泛型,以及各种关系箭头(继承 `<|--`、组合 `*--`、聚合 `o--`、关联 `--`、依赖 `..>`)。它不是完整 UML —— 没有泳道,也没有完整的活动图语义 —— 但写工程文档的时候这反而是好事,能逼着你写简单点。真要完整 UML,那多半是拿错工具了。
对话模式里 AI 会先问你两三个问题 —— 谁参与、发生什么、异常分支怎么走 —— 弄清楚了再动笔。
教程里讲了常用符号、几种基本结构、九条画法规范,还有可以直接拿去用的 prompt 模板和真实业务例子。