现代软件工程建模体系的演进与重构
在过去二十多年里，UML（Unified Modeling Language）几乎等同于“软件工程标准语言”。
无论是大学教材、企业开发规范，还是大型系统设计文档，UML 都长期占据核心位置：
类图（Class Diagram）
时序图（Sequence Diagram）
用例图（Use Case）
状态图（State Machine）
活动图（Activity Diagram）
部署图（Deployment Diagram）
曾经的软件工程体系甚至默认：
“没有 UML 的系统，不算真正完成设计。”
但近几年，一个明显趋势正在发生：
大量团队不再维护 UML 文档
架构设计开始全面转向 Mermaid + Markdown
OpenAPI 逐渐取代接口类图
云原生体系几乎完全依赖 YAML / IaC
微服务系统更关注 Runtime 与事件流，而不是对象结构
AI 工程开始使用 Workflow、Graph、DAG 描述系统行为
于是一个问题开始出现，UML 是否已经被淘汰？
答案其实比“淘汰”复杂得多。
UML 并没有消失，它只是从“核心工程语言”，退化成了“特定场景下的辅助建模工具”。
而真正发生变化的，其实是整个软件工程范式。
一、UML 为什么曾经如此成功？
UML 的成功，本质上属于“面向对象时代”的成功。
在 2000 ~ 2015 年期间，主流企业开发模式仍然是：
Java EE
.NET
C++
SOA
单体架构
瀑布式流程
那个时代的软件复杂度主要来自：
类之间的继承关系
模块之间的调用关系
生命周期管理
接口设计
对象协作
因此 UML 非常适合表达：
静态结构
对象关系
模块边界
组件组织
典型开发流程通常是：
需求分析
UML 建模
数据库设计
编码开发
测试交付
在这种模式下“先建模，再开发”是合理的。
因为系统变化速度相对可控。
二、真正变化的不是 UML，而是软件工程本身
今天很多人误以为：
Mermaid 替代了 UML。
实际上并不是。
真正发生变化的是：软件工程已经从“静态结构工程”转向了“动态系统工程”。
过去的软件复杂度主要来自代码结构
今天的软件复杂度则更多来自系统协同
现代系统真正困难的部分，已经不再是：
类怎么继承
接口怎么实现
模块如何组织
而变成了：
微服务如何协同
数据如何流转
事件如何传播
状态如何演进
Runtime 如何治理
Workflow 如何编排
云原生如何调度
这也是 UML 开始“失去中心地位”的根本原因。
因为 UML 天然偏向“静态对象建模”
而现代系统更强调“动态运行时协同”
三、为什么 UML 越来越难维护？
1. UML 过于重量级
完整 UML 体系包含大量图形：
类图
用例图
时序图
活动图
部署图
包图
协作图
状态图
通信图
组件图
问题在于：
现实开发里，没有团队能够长期维护这些内容。
尤其是在：
敏捷开发
DevOps
高频迭代
微服务拆分
环境下。
最终往往会出现：
代码已经变了
图却还停留在半年前
于是 UML 很容易退化成“交付物文档”
而不是“真实系统描述”
2. UML 强依赖面向对象体系
UML 的核心思想来自：OO（Object-Oriented）
但现代系统越来越：
API-first
Event-driven
Workflow-driven
Data-driven
Function-driven
今天架构师更关注的是：
服务边界
数据边界
事件流
Saga
Stream
状态流转
而不是class UserService extends BaseService
这导致 UML 的很多建模方式开始显得“不贴近现实”。
3. 云原生系统无法被 UML 很好表达
现代系统的复杂度已经扩展到：
Kubernetes
Service Mesh
Kafka
Redis
CDC
ETL
DAG
GPU Scheduling
AI Workflow
这些运行时协同关系：
UML 的表达能力其实比较弱。
例如：
今天一个 AI Agent 系统真正复杂的部分可能是：
LLM 调度
上下文传播
工具链路
事件反馈
任务状态机
Workflow DAG
而不是类之间如何继承
四、现代软件工程到底在使用什么？
这里必须明确：
现代软件工程并不是“没有建模”。
而是建模方式发生了彻底变化。
五、Mermaid：现代团队的轻量化建模标准
如今大量团队开始使用 Mermaid。
原因很现实：
Markdown 原生支持
Git 友好
文本化
AI 易生成
易于维护
与文档系统天然融合
例如：
graph TD
A[Client]
--> B[API Gateway]
B --> C[User Service]
B --> D[Order Service]相比传统 UML 工具：
Mermaid 最大优势并不是“图更好”。
而是：它更适合现代协作体系。
尤其是在 GitHub、GitLab、Notion、Obsidian、AI 生成文档 等场景中。
六、C4 Model：现代架构设计真正的核心
传统 UML 关注：类
而现代架构更关注：系统边界
于是 C4 Model 开始崛起。
它分为四层：
Context
Container
Component
Code
相比 UML：
C4 最大变化是：从“对象视角”转向“系统视角”
这对于 微服务、云原生、分布式系统来说非常重要。
如今很多大型系统设计实际上已经形成 C4 + Mermaid 的组合体系。
七、OpenAPI 为什么会彻底替代接口 UML？
过去接口通常通过 类图、时序图、文档 表达。
现在大量团队直接使用 OpenAPI：
paths:
/users:
get:
因为现代工程需要的已经不是“可阅读文档”，而是“可执行文档”
OpenAPI 的优势在于它不仅描述接口，还能：
自动生成文档
自动生成 SDK
自动 Mock
自动校验
自动测试
这意味着：文档本身已经成为系统的一部分。
八、现代系统真正重要的能力是什么？
很多开发者仍然停留在代码结构设计阶段。
但现代系统更重要的是：
1. 系统边界
例如：
用户域
订单域
支付域
这实际上对应 DDD（领域驱动设计）中的 Bounded Context
2. 数据流
现代系统本质上已经是：数据流系统
例如：
请求流
事件流
缓存流
日志流
数据同步流
3. 状态流转
复杂系统的核心复杂度：
其实来自：状态管理
例如：
Pending
→ Running
→ Retry
→ Failed
→ Rollback
→ Success这也是为什么：
状态机设计越来越重要。
4. Event-driven
现代系统正在从同步调用转向事件传播：
Kafka、MQ、Stream、Saga 的重要性不断提高。
5. Runtime 思维
过去关注：代码如何组织
现在关注：系统如何运行
这也是 Observability（可观测性）越来越重要的根本原因。
九、现代工程体系应该如何学习？
基于当前行业趋势，一个更合理的学习路线应该是：
第一阶段：轻量化表达能力
建议优先学习：
Mermaid
ER 建模
基础时序图
目标：学会表达系统。
第二阶段：现代架构能力
重点学习：
OpenAPI
C4 Model
微服务边界设计
目标：学会设计系统。
第三阶段：高级业务抽象能力
重点学习：
状态机
DDD
Event-driven
目标：学会抽象复杂业务。
第四阶段：企业级协同体系
长期学习：
BPMN
Saga
CQRS
Event Sourcing
Workflow Orchestration
目标：掌握复杂系统协同。
十、UML 真的还有价值吗？
有。但价值已经集中在少数领域，例如：
时序交互
状态生命周期
DDD 领域建模
复杂业务状态表达
特别是：UML Sequence Diagram
实际上今天仍然非常有价值。
只是很多团队已经不用传统 UML 工具，而改用 Mermaid SequenceDiagram 来表达。
十一、AI 时代会进一步削弱 UML
AI 更适合理解：
YAML
Mermaid
JSON Schema
OpenAPI
Workflow
DAG
Runtime Trace
因为这些内容更接近真实系统。
未来的软件工程会越来越强调可机器理解的工程描述，而不是传统静态文档。
十二、结语
UML 并没有死亡。
它只是失去了“软件工程中心”的地位。
真正改变世界的，并不是某一个替代工具。
而是整个软件工程已经从“静态结构设计”进入“动态系统协同”时代。
未来真正重要的能力，也不再是类如何设计，而是：
系统如何协同
状态如何流转
事件如何传播
数据如何演进
服务如何自治
这才是现代软件工程真正的核心。