学习总结

我理解的 UML

我们期望通过一种方式传递架构设计和方案。拉上团队成员，在一块白板上借助简单的图形和箭头来表达，假如团队成员之间有很强的默契，一点就能互相心神领会并且能够保持长期清晰的记忆。很显然这是简单的方式，但也是一种完美的假设。现实情况是：灵魂队友求之不得，粗放的设计问题频出，沟通的信息衰减超出你我想象，还有记忆这个事就跟发量一样，你奈何不了。

再者，通过白板来表达设计意图，大伙的创造力是不可小觑的。讨论会上，在当事人一顿解释下你已经弄明白这个箭头，那个形状和不同的颜色代表什么意思，事隔两个周末后，或许你的记忆就变得模糊了。甚至包括当时画图的那位作者。很有可能在你们复盘的时候，原本通过灵魂默契理解的场景会变成一场重新定义图例的嘴仗。

于是通过图形统一建模的标准自然就变得极为重要。

从 97 年 UML 标准建立，到鼎盛时代 UML 相关的工具多达 170 种左右。他所解决的痛点之痛，能够感受。

如今业界有种声音说 UML 已死，是因为它的规范太严谨，太完备；结构型、行为型能几乎覆盖你要传递设计的所有细节，图示让你从入门到放弃；你花了大量的时间去熟悉它的规范，但实际应用的图例可能只占一小部分；好多时候是觉得它严谨的过于啰嗦，啰嗦到大伙不太想用了。

在大行敏捷的当下，推崇最小化设计，短周期交付，小步迭代，持续重构。这与瀑布流式的开发已经迥异，少了一次到位的大规模的整体设计，但传递设计和方案的目标依然存在。敏捷并没有省略某个步骤，而是在优化各个环节。比如 UML，我们可以简化它啰嗦的部分，精简到不需要灵魂队友也可以完整的传递设计意图，并且能够长久保鲜，岂不悠哉！

比如，UML 类图种各类的箭头可以简化，使用最简单的箭头，链接的对象可以通过不同的图示（比如接口的图示）和描述（接口用 I 开口，抽象类用 Abstract 开头），甚至还可以附加一些文字在箭头旁边来辅助说明下他们之间的联系。李老师也多次强调，不要纠结细节，不要纠结规范，我们的目标是找到一种最好用的方法来传递架构设计和方案。

架构图一定是重要的，因为你需要建立基本共识上的沟通，UML 也仍旧是好用的工具。

架构视图

4+1 架构视图提出单一的视图无法完整的表达架构，需要具备完整的视图集。在设定的场景下，使用不同的视图让不同的相关人员了解架构的细节。在实践的开发中，4+1 视图是给我们一个设计架构视图的维度方面的启发，让我们关注这些点。

了解 4+1 视图后，直接想到 C4 模型。

C4 代表上下文（Context）、容器（Container）、组件（Component）和代码（Code）——一 系列分层的图表，可以用这些图表来描述不同缩放级别的软件架构，每种图表都适用于不同的受众。可以将其视为代码的谷歌地图。

C4 是一种动态的方式实践，比如，4 个层级可以对应到业务用例，系统用例，组件图/时序图和类图 几类图来表述清楚。同样，他也是敏捷对设计环节优化的产物。

规范，工具很重要，但更重要的是如何落地实践。建模是个动态的过程，需要理论基础结合大量的实践。希望后续能够学习多点实践的案例剖析。