架构师画了100张图，老板说"挺好"——然后项目失败了

你有没有遇到过这种场景：

架构师花了一周，画了一套"完美"的架构图，给开发讲——开发说"看不懂，你这个类怎么没画出来"；给运维讲——运维说"你这个部署在哪？服务器呢"；给老板汇报——老板说"挺好挺好"；然后项目失败了，没人知道问题出在哪。

这不是哪个人的问题。这是一种图，根本装不下一个系统。

Kruchten何许人？他解决了什么问题

1995年，Philippe Kruchten（ Rational Software的首席架构师）提出了一个看似简单、实则革命性的观点：软件架构需要从5个不同视角来描述，而不是一张图打天下。

这就是"4+1"视图模型。4个基础视图，加上1个场景视图——场景视图是驱动其他四个视图的那个"+1"。

为什么这很重要？因为系统架构的"涉众"天然是多元的：产品经理关心功能，开发关心代码组织，运维关心部署，网络工程师关心拓扑，老板只关心"能不能按时上线"。

用一个视角去满足所有人，结果是所有人都觉得差一口气。

关注点：功能需求

这个系统要做什么？有哪些模块？模块之间的关系是什么？

用到的UML图：类图、对象图。描述手段是Booch方法和OMT方法。

对应人群：最终用户、需求分析师、产品经理。

说白了，逻辑视图回答的是"这个系统解决什么问题"。

关注点：并发、同步、性能

系统运行时，有哪些进程/线程？它们怎么通信？同步机制是什么？

用到的UML图：序列图、活动图、状态图。

对应人群：系统集成师、开发人员。

进程视图回答的是"系统运行时是怎么运转的"。如果你关心吞吐量、响应时间、线程安全，这个视图是主战场。

关注点：软件开发组织

代码怎么组织？分了多少层？模块之间的依赖关系是什么？谁依赖谁？

用到的UML图：包图、组件图。

对应人群：程序员、软件项目经理。

开发视图回答的是"代码怎么组织方便开发和维护"。这是开发人员每天打交道最多的视角。

#AI工程