。C4模型通过不同的抽象层级来表达系统的静态结构，并提供了最小集的抽象建模元素，为设计人员提供了一种低认知负载、易于学习和使用的高效建模方式。
。因此，对于软件系统架构进行可视化表达是有价值，且是必要的。
软件架构可视化的方式有多种，不同的团队有不同的实践方式，最为常见的由如下几种：
不同的可视化方式各有优劣，以下部分将对不同的表现形式进行说明
1.1 可视化方式-线框图
线框图是最为通用的可视化表达方式之一，架构师或设计人员大量的架构图，比如技术架构、功能架构、数据架构、逻辑架构等等都通过线框图的形式表达。该种可视化方式的优势是：
语义的一致性问题
”。举个简单的场景，如果我们在百度搜索 “架构图” ，你可能得到以下结果：
：不同形状和颜色的图形元素、不同形状和颜色的连线、不同的意图。
。虽然都是通过线框表达软件系统架构，但不同的人可能使用不同的元素、不同的颜色、不同的连线和分层等等，线框*表达的灵活性和图形化语义的一致性存在潜在冲突，最终都会阻碍架构设计意图传达。
1.2 可视化方式-UML
。简单来说，UML提供了大家达成一致的（UML支持扩展的场景除外）建模元素。如果团队成员比较熟悉UML，那么通过UML表达的系统架构图天然具有认知一致性。
Simon Brown给出的数据，实际情况只有少数团队真正使用UML。不论是UML的复杂度和学习成本原因，还是敏捷化下对UML的排斥，很多团队都放弃了UML。
我们不能否认UML的价值，基于统一建模语言能够更有效的进行架构设计的信息传递和沟通，也能基于UML提供的详细的模型图元素进行充分的设计表达。团队中是否要基于UML进行沟通需要权衡，虽然UML不能表达你所要传达的全部的架构信息，但其在某些维度的表达相对比较适合。
1.3 可视化方式-草图
的图形化方式。团队基于特定的场景，可以通过草图的形式进行快速的沟通，以便高效的在干系人间拉齐关键信息。
语义一致性低
。如果干系人没有完全参与到草图的讨论，又或是后置查看，大概也很难精准捕获这些草图所要表达的设计意图。
2 C4 模型
2.1 C4模型的统一抽象
团队需要统一语言进行高效沟通 !!!
。如下图所示：
2.2 上下文图：System Context Diagram
。
系统上下文图正是从高层视角表述待构建系统与当前IT设施的交互及边界。通过上下文图：
2.3 容器图：Container Diargram
系统由哪些容器组成？容器的职责是什么？以及相关的高层的技术选型是什么？
与Docker的容器概念不同，C4模型的容器是在 “系统” 作用域之下，其表达的是组成系统的可独立可部署的物理单元。以下图为例：单个容器元素重包含了名称、职责描述、技术选型，同时，容器间的连线及标注标识了其高层的交互协议及交互形式。
2.4 组件图：Component Diagram
进一步的剖析容器，回答：容器由哪些组件组成？这些组件的职责及组件间的交互形式是什么？
具体到每个容器内部，通过多个组件及组件间的关系表达容器的组成。“组件” 本身是一个泛化的概念，C4模型的组件是在 “容器” 的作用域之下，其表现形式可能是独立的Jar包，或者是应用内独立的包，也可能是类级别，但逻辑上都能够表达一个组件的概念。对于组件图关键的是要表示清楚组件的实现选型、组件职责以及组件间的交互关系。
2.5 代码
，比如，我们非常关注系统设计的可扩展性，则关键部分可能需要一些类图表达；又或者非常关注底层数据模型，则E-R图可以纳入考虑范围。
3 C4模型实践中的决策和问题
连线表达依赖关系还是数据流向 ？
。实践中一般通过合理的文字说明来明确的表达元素间的关系。
Jar或类库应该建模为“容器”？ “组件” ？
Jar包或类库一般是链接到调用方的进程中，作为进程中的一部分存在，这种依赖一般不表示为容器，而是组件。当然，是否要将Jar，比如SDK表示为组件并体现在组件图上需要设计人员具体情况具体分析。
数据存储系统应该建模为 “软件系统” 还是 “容器” ？
数据存储系统，比如MySQL、DFS等一般是作为独立的外部存储集群存在，集群的运维可能归属于公司的运维团队。以OSS为例，但从应用角度而言，即使集群的运维不归属当前开发团队，团队也会申请租户隔离的专属空间，因此，在C4模型中这种情况应该表述为 “容器”。
消息系统应该如何建模 ？
消息系统一般作为两个容器间的交互媒介，因此在C4模型中消息系统的建模存在两种方式：
图形化的过期问题
，由上到下逐渐增大，上下文图的变化频率最小，而代码级则变化最大。
为什么C4不涉及业务流、状态机、数据模型等建模
C4模型仅对系统的静态结构进行建模，并不试图囊括或替代其它建模方式，C4模型并不适合所有维度的可视化表达。对于业务流可以基于BPML、UML活动图进行表达，状态机可以基于UML状态机图进行表达，而数据模型可以通过E-R图表达，不同建模语言相互补充。
4 系统架构设计关注不同维度
作为架构师或系统设计人员，在进行系统架构设计时一般会关注不同维度，一般情况下，对于业务系统建设而言，会关注以下维度。在架构设计（架构和设计）过程中，基于C4模型、UML及BPML等多种建模方式相互补充，不同表现维度下可以采用不同的建模方式
5 总结
的高效的建模方式。在实际项目落地过程中，结合C4模型以及UML、线框图等组合方式对架构设计进行可视化表达，一定程度上能够提升团队对架构设计认知的一致性以及建模效率。
作者：倪新明