软件架构可视化及C4模型，架构设计不仅仅是UML

Tech

导读

软件系统架构设计的目标不在于设计本身，而在于架构设计意图的传达。图形化有助于在团队间进行高效的信息同步，但不同的图形化方式需要语义一致性和效率间实现平衡。C4模型通过不同的抽象层级来表达系统的静态结构，并提供了最小集的抽象建模元素，为设计人员提供了一种低认知负载、易于学习和使用的高效建模方式。

01 为什么要进行架构可视化？


在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了！

软件系统架构设计的目标不在于设计本身，而在于架构设计意图的传达。如果不能清晰、一致的在干系人间进行设计意图的同步，即使再好的设计也只是空中楼阁。软件架构设计本质上也是一种抽象和建模的过程，软件架构设计模型的表达有多种方式：图形化、语言和文字。绝大部分场景下，图形化在架构设计的表现力层面效果更佳。因此，对于软件系统架构进行可视化表达是有价值，且是必要的。

软件架构可视化的方式有多种，不同的团队有不同的实践方式，最为常见的由如下几种：

• 线框图：通过线框图和连线表达架构元素及之间的关系

• UML：统一建模语言，表达系统的静态结构和动态行为

• 草图：非正式的图形

不同的可视化方式各有优劣，以下部分将对不同的表现形式进行说明

1.1  可视化方式—线框图

    线框图是最为通用的可视化表达方式之一，架构师或设计人员大量的架构图，比如技术架构、功能架构、数据架构、逻辑架构等等都通过线框图的形式表达。该种可视化方式的优势是：

• 建模工具多样化：你可以基于Viso、Drawio、PPT等任何一款支持线框图的软件进行建模工作

• 学习成本低：设计人员几乎不需要进行专门的建模语言以及建模工具的学习，门槛较低

但，基于线框图表达软件系统架构存在的问题也非常明显：语义的一致性问题。

你可能自己画过很多软件系统架构图，也可能参与评审过其他团队的架构图，相信，对你而言并不是的所有的图都是“清晰且易于理解的”。举个简单的场景，如果在百度搜索 “架构图” ，你可能得到以下结果：

图1.百度搜索 “架构图”可能得到结果各式各样的 “架构图”：不同形状和颜色的图形元素、不同形状和颜色的连线、不同的意图。可以看出：线框图虽然简单，但其图形化的语义一致性是大问题。虽然都是通过线框表达软件系统架构，但不同的人可能使用不同的元素、不同的颜色、不同的连线和分层等等，线框自由表达的灵活性和图形化语义的一致性存在潜在冲突，最终都会阻碍架构设计意图传达。

1.2  可视化方式—UML

    UML是统一建模语言，相比于线框图而言，其优势是在软件建模层面提供了一致性的建模元语言。简单来说，UML提供了大家达成一致的（UML支持扩展的场景除外）建模元素。如果团队成员比较熟悉UML，那么通过UML表达的系统架构图天然具有认知一致性。丰富灵活的建模元语言在提升语义一致性的同时，也必然会导致复杂性的上升。掌握UML具有一定的学习成本，而熟练的应用对研发人员也提出了更高的要求。基于 Simon Brown给出的数据，实际情况只有少数团队真正使用UML。不论是UML的复杂度和学习成本原因，还是敏捷化下对UML的排斥，很多团队都放弃了UML。不能否认UML的价值，基于统一建模语言能够更有效的进行架构设计的信息传递和沟通，也能基于UML提供的详细的模型图元素进行充分的设计表达。团队中是否要基于UML进行沟通需要权衡，虽然UML不能表达你所要传达的全部的架构信息，但其在某些维度的表达相对比较适合。

• 表达流程和工作流可以采用UML活动图

• 表达运行时的交互可以采用UML时序图

• 表达领域模型或者设计模式可以采用UML类图

• 表达状态转换可以采用UML状态机

• 表达系统的部署结构可以使用UML部署图

1.3  可视化方式—草图

    架构可视化另一个非常常见的方式是：草图。草图是一种非正式的、易于快速沟通的图形化方式。团队基于特定的场景，可以通过草图的形式进行快速的沟通，以便高效的在干系人间拉齐关键信息。但，草图的劣势与线框图一样：语义一致性低。

可以在白板上 “随心所欲” 地画各式各样的草图，草图上的元素、连线，又或者布局都可能是涌现式的、临时性的，这些草图的价值在于 “会话周期内的高效沟通”。如果干系人没有完全参与到草图的讨论，又或是后置查看，大概也很难精准捕获这些草图所要表达的设计意图。

图2.图片引自 https://c4model.com/

02   C4模型  

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。

2.1  C4模型的统一抽象

    

团队需要统一语言进行高效沟通 !!!

C4模型在不同的级别提供了统一的抽象以表达软件系统的静态结构。如下图所示：

图3.图片引自 https://c4model.com/

• 软件系统：最顶层的抽象，其对用户提供价值。包含待构建的系统以及外部依赖的系统

• 容器：表示一个应用或者数据存储，容器需要运行以支持系统的正常运转。每个容器都是独立部署或运行的单元，容器间的通信一般式跨进程交互

• 组件：提供一定能力封装的单元。在C4模型上下文中，组件不是独立部署的单元，一般情况下运行于容器之中。

• 代码：系统的实现细节相关

• 人：系统的使用用户

2.2  上下文图：System Context Diagram

    

要构建的系统不会孤立存在，都会依赖现有的IT设施。要明确我们构建的系统是什么，宏观上需要回答：系统如何融入到现有的IT设施。

系统上下文图正是从高层视角表述待构建系统与当前IT设施的交互及边界。通过上下文图：

• 展示与软件系统交互的各方及相互关系

• 展示软件系统与外部环境的边界

• 作为了解系统架构的切入点
• 确保所有人都理解、认可系统的工作范围

图4.图片引自 https://c4model.com/

2.3  容器图：Container Diargram

    

更进一步的剖析核心系统，回答：系统由哪些容器组成？容器的职责是什么？以及相关的高层的技术选型是什么？

与Docker的容器概念不同，C4模型的容器是在 “系统” 作用域之下，其表达的是组成系统的可独立可部署的物理单元。以下图为例：单个容器元素重包含了名称、职责描述、技术选型，同时，容器间的连线及标注标识了其高层的交互协议及交互形式。

图5.图片引自 https://c4model.com/

2.4  组件图：Component Diagram

    

进一步的剖析容器，回答：容器由哪些组件组成？这些组件的职责及组件间的交互形式是什么？

具体到每个容器内部，通过多个组件及组件间的关系表达容器的组成。“组件” 本身是一个泛化的概念，C4模型的组件是在 “容器” 的作用域之下，其表现形式可能是独立的Jar包，或者是应用内独立的包，也可能是类级别，但逻辑上都能够表达一个组件的概念。对于组件图关键的是要表示清楚组件的实现选型、组件职责以及组件间的交互关系。

图6.图片引自 https://c4model.com/

2.5  代码

    

代码处于C4模型的最低层，且是可选的，其关注的是实现相关。C4模型并没有对实现层面的可视化进行统一抽象，开发人员可以选择UML类图、E-R图等进行可视化。是否需要提现代码层面研发人员基于具体情况具体分析，一般情况下，如果系统中需要重点关注的部分可以考虑一些代码级别的图支持，比如，如果非常关注系统设计的可扩展性，则关键部分可能需要一些类图表达；又或者非常关注底层数据模型，则E-R图可以纳入考虑范围。

图7.图片引自 https://c4model.com/

03   

C4模型实践中的决策和问题

  

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。

连线表达依赖关系还是数据流向？

都可以，C4模型中的连线既可以表达依赖方向，也可以表达数据流向。原则上，设计人员需要保证其清晰且无歧义。实践中一般通过合理的文字说明来明确的表达元素间的关系。

Jar或类库应该建模为“容器”？“组件”？

Jar包或类库一般是链接到调用方的进程中，作为进程中的一部分存在，这种依赖一般不表示为容器，而是组件。当然，是否要将Jar，比如SDK表示为组件并体现在组件图上需要设计人员具体情况具体分析。

数据存储系统应该建模为 “软件系统” 还是 “容器”？

数据存储系统，比如MySQL、DFS等一般是作为独立的外部存储集群存在，集群的运维可能归属于公司的运维团队。以OSS为例，但从应用角度而言，即使集群的运维不归属当前开发团队，团队也会申请租户隔离的专属空间，因此，在C4模型中这种情况应该表述为 “容器”。

消息系统应该如何建模？

消息系统一般作为两个容器间的交互媒介，因此在C4模型中消息系统的建模存在两种方式：

• 依赖消息系统的容器都显示与消息系统交互，明确的表达各自与消息系统的依赖关系或数据流向

• 屏蔽消息系统，只体现容器间的依赖关系，并对依赖进行明确说明

图形化的过期问题

C4模型本身也是一种文档化机制，同样也存在过期问题。只不过C4模型通过对系统在不同的层级进行抽象，每个抽象层级的过期频率不同，由上到下逐渐增大，上下文图的变化频率最小，而代码级则变化最大。

为什么C4不涉及业务流、状态机、数据模型等建模

C4模型仅对系统的静态结构进行建模，并不试图囊括或替代其它建模方式，C4模型并不适合所有维度的可视化表达。对于业务流可以基于BPML、UML活动图进行表达，状态机可以基于UML状态机图进行表达，而数据模型可以通过E-R图表达，不同建模语言相互补充。

04   

系统架构设计关注不同维度

  

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。

作为架构师或系统设计人员，在进行系统架构设计时一般会关注不同维度，一般情况下，对于业务系统建设而言，会关注以下维度。在架构设计（架构和设计）过程中，基于C4模型、UML及BPML等多种建模方式相互补充，不同表现维度下可以采用不同的建模方式

• 业务流程：泳道图或UML活动图，表达核心的业务流

• 业务用例、系统用例：UML用例图

• 领域模型：UML类图

• 系统边界：C1，系统上下文图

• 高层技术选型：C2，容器图

• 系统职责分配：用线框图表示功能架构

• 关键部分的实现：C3，组件图

• 系统关键的交互逻辑：UML时序图

• 数据模型：E-R图

• 关键实体的状态机：UML状态机图

• 不同的高优先级架构属性的设计：比如，缓存方案、幂等性设计方案、定时任务补偿策略、降级限流策略等等，这些都与具体的需求所关注的高优先级的架构属性相关。

• 部署架构：UML部署图

05   总结  

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目

软件架构设计的终极目标不在于设计本身，而在于架构设计意图的传达。图形化有助于在团队间进行高效的信息同步，但不同的图形化方式在语义一致性和效率间存在平衡。C4模型通过不同的抽象层级来表达系统的静态结构，并提供了最小及的抽象建模元素，为设计人员提供了一种低认知负载、易于学习和使用的高效的建模方式。在实际项目落地过程中，结合C4模型以及UML、线框图等组合方式对架构设计进行可视化表达，一定程度上能够提升团队对架构设计认知的一致性以及建模效率。

推荐阅读三十分钟入门基础Go
随机高并发查询结果一致性设计实践
京东金融Android瘦身探索与实践
从代码到设计的性能优化指南

求分享

求点赞

求在看

打造SAAS化服务的会员徽章体系，可以作为标准的产品化方案统一对外输出。结合现有平台的通用能力，实现会员行为全路径覆盖，并能结合企业自身业务特点，规划相应的会员精准营销活动，提升会员忠诚度和业务的持续增长。▪底层能力：维护用户基础数据、行为数据建模、用户画像分析、精准营销策略的制定

▪功能支撑：会员成长体系、等级计算策略、权益体系、营销底层能力支持

▪用户活跃：会员关怀、用户触达、活跃活动、业务线交叉获客、拉新促活