UML 类图示例

下面这些案例展示了不同开发团队如何在各类系统中建模领域逻辑、继承层次和服务边界。参考这些模式，可以跨语言和框架复用。

使用这个类图模板返回模板页

真实案例

用户认证系统

使用场景: 后端开发者，设计认证服务

User { id: UUID, email: string, passwordHash: string }

+ login(email, password): Token

+ logout(token): void

+ resetPassword(email): void

Token { value: string, expiresAt: DateTime, userId: UUID }

Role { name: string, permissions: string[] }

User *── * Role（多对多）

这样组织的原因: 在实现之前建模认证，会提前暴露设计问题：Token 应该是值对象还是实体？Role 和 Permission 应该分开吗？画图强迫在写代码前做出这些决定。

内容管理系统

使用场景: 全栈开发者，构建博客平台

Article { id, title, body, status: Draft|Published }

+ publish(): void + archive(): void

Author { id, name, bio } ──1 Article

Tag { name } *── * Article

Comment { body, createdAt } *── 1 Article

MediaAsset { url, mimeType } *── * Article

这样组织的原因: Article上的Status枚举和与Tag的多对多关系，推动了用关联表而非JSON列的决策——这个权衡在没有图的情况下很容易被忽略。

支付处理领域

使用场景: 平台工程师，设计支付抽象层

PaymentMethod（抽象）{ id, userId }

← CreditCard { last4, expiry, token }

← BankAccount { accountNumber, routingNumber }

Payment { id, amount, currency, status }

+ process(): Result + refund(amount): void

Payment *── 1 PaymentMethod

Refund { id, amount, reason } *── 1 Payment

这样组织的原因: 抽象的PaymentMethod类和具体子类清晰展示了策略模式。评审者不需要读代码就能看懂多态设计意图。

库存管理系统

使用场景: 开发者，设计仓库管理后端

Product { sku, name, description }

InventoryItem { quantity, warehouseId, reservedQty }

1 ── * Product

StockMovement { type: In|Out|Transfer, quantity, timestamp }

*── 1 InventoryItem

PurchaseOrder { status, expectedDelivery }

1 ── * PurchaseOrderLine { product, quantity, unitCost }

这样组织的原因: StockMovement作为不可变事件日志（而非直接更新数量）是一个关键的架构决策，图让整个团队都清晰看到了这个选择。

通知服务

使用场景: 工程师，设计多渠道通知系统

Notification（抽象）{ id, userId, createdAt, + send() }

← EmailNotification { subject, htmlBody, recipient }

← PushNotification { title, body, deviceToken }

← SMSNotification { phone, message }

NotificationPreference { userId, channel, enabled }

NotificationTemplate { name, subject, body }

这样组织的原因: 抽象基类强制了统一的send()接口。新增渠道意味着继承Notification——图向未来的贡献者传达了这个扩展点。

微服务领域边界

使用场景: 架构师，为大型电商平台定义服务边界

OrderService: Order, OrderItem, OrderStatus

CatalogService: Product, Category, PriceRule

UserService: User, Address, PaymentMethod

FulfillmentService: Shipment, Tracking, Warehouse

─── 跨服务引用只传ID，不传对象引用

这样组织的原因: 用类图展示领域边界（而非基础设施）帮助团队执行服务间通过ID和事件通信的原则，而不是共享对象引用。

使用技巧

类图聚焦于一个限界上下文或领域区域——试图在一张图里展示整个系统只会产生无法阅读的混乱。
优先展示最重要的关系，而不是力求完整——一张有30个类和50条箭头的图什么都传达不了。
一致使用可见性修饰符（+/-/#）来展示类的预期公共API，而不只是内部字段。
类图是设计工具，不是真理之源。只为架构仍在积极演进的区域持续维护它。

在线开始编辑

回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。

使用这个模板： /editor/new?template=class-diagram

使用这个类图模板