共计 4138 个字符，预计需要花费 11 分钟才能阅读完成。
软件系统架构设计的指标不在于设计自身，而在于 架构设计用意的传播 。图形化有助于在团队间进行高效的信息同步，但不同的图形化形式须要 语义一致性和效率间实现均衡。C4 模型通过不同的形象层级来表白零碎的动态构造，并提供了最小集的形象建模元素，为设计人员提供了一种低认知负载、易于学习和应用的高效建模形式。
1 为什么要进行架构可视化？
软件系统架构设计的指标不在于设计自身，而在于架构设计用意的传播。如果不能清晰、统一的在干系世间进行设计用意的同步，即便再好的设计也只是海市蜃楼。软件架构设计实质上也是一种形象和建模的过程（对模型和形象的实质参考文章《畛域驱动设计开篇》），软件架构设计模型的表白有多种形式：图形化、语言和文字。绝大部分场景下，图形化在架构设计的表现力层面成果更佳。因而，对于软件系统架构进行可视化表白是有价值，且是必要的。
软件架构可视化的形式有多种，不同的团队有不同的实际形式，最为常见的由如下几种：
• 线框图：通过线框图和连线表白架构元素及之间的关系
• UML：对立建模语言，表白零碎的动态构造和动静行为
• 草图：非正式的图形
不同的可视化形式各有优劣，以下局部将对不同的表现形式进行阐明
1.1 可视化形式 - 线框图
线框图是最为通用的可视化表达方式之一，架构师或设计人员大量的架构图，比方技术架构、性能架构、数据架构、逻辑架构等等都通过线框图的模式表白。该种可视化形式的劣势是：
• 建模工具多样化：你能够基于 Viso、Drawio、PPT 等任何一款反对线框图的软件进行建模工作
• 学习成本低：设计人员简直不须要进行专门的建模语言以及建模工具的学习，门槛较低
但，基于线框图表白软件系统架构存在的问题也非常明显：语义的一致性问题
你可能本人画过很多软件系统架构图，也可能参加评审过其余团队的架构图，我置信，对你而言并不是的所有的图都是“清晰且易于了解的”。举个简略的场景，如果咱们在百度搜寻“架构图”，你可能失去以下后果：
各式各样的“架构图”：不同形态和色彩的图形元素、不同形态和色彩的连线、不同的用意。
咱们能够看出：线框图尽管简略，但其其图形化的语义一致性是大问题。尽管都是通过线框表白软件系统架构，但不同的人可能应用不同的元素、不同的色彩、不同的连线和分层等等，线框自在表白的灵活性和图形化语义的一致性存在潜在抵触，最终都会妨碍架构设计用意传播。
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 C4 模型
2.1 C4 模型的对立形象
团队须要对立语言进行高效沟通 !!!
C4 模型在不同的级别提供了对立的形象以表白软件系统的动态构造。如下图所示：
• 软件系统：最顶层的形象，其对用户提供价值。蕴含待构建的零碎以及内部依赖的零碎
• 容器 ：示意一个利用或者数据存储，容器须要运行以支持系统的失常运行。 每个容器都是独立部署或运行的单元，容器间的通信个别式跨过程交互
• 组件 ：提供肯定能力封装的单元。 在 C4 模型上下文中，组件不是独立部署的单元，个别状况下运行于容器之中。
• 代码：零碎的实现细节相干
• 人：零碎的应用用户
2.2 上下文图：System Context Diagram
咱们要构建的零碎不会孤立存在，都会依赖现有的 IT 设施。要明确咱们构建的零碎是什么，宏观上须要答复：咱们的零碎如何融入到现有的 IT 设施。
零碎上下文图正是从高层视角表述待构建零碎与以后 IT 设施的交互及边界。通过上下文图：
• 展现 与软件系统交互的各方及互相关系
• 展现 软件系统与外部环境的边界
• 作为理解零碎架构的切入点
• 确保所有人都了解、认可零碎的工作范畴
2.3 容器图：Container Diargram
更进一步的分析外围零碎，答复：零碎由哪些容器组成？容器的职责是什么？以及相干的高层的技术选型是什么？
与 Docker 的容器概念不同，C4 模型的容器是在“零碎”作用域之下，其表白的是组成零碎的可独立可部署的物理单元。以下图为例：单个容器元素重蕴含了名称、职责形容、技术选型，同时，容器间的连线及标注标识了其高层的交互协定及交互模式。
2.4 组件图：Component Diagram
进一步的分析容器，答复：容器由哪些组件组成？这些组件的职责及组件间的交互模式是什么？
具体到每个容器外部，通过多个组件及组件间的关系表白容器的组成。“组件”自身是一个泛化的概念，C4 模型的组件是在“容器”的作用域之下，其表现形式可能是独立的 Jar 包，或者是利用内独立的包，也可能是类级别，但逻辑上都可能表白一个组件的概念。对于组件图要害的是要示意分明组件的实现选型、组件职责以及组件间的交互关系。
2.5 代码
代码处于 C4 模型的最低层，且是可选的，其关注的是实现相干。C4 模型并没有对实现层面的可视化进行对立形象，开发人员能够抉择 UML 类图、E- R 图等进行可视化。是否须要提现代码层面研发人员基于具体情况具体分析，个别状况下，如果零碎中须要重点关注的局部能够思考一些代码级别的图反对，比方，咱们十分关注零碎设计的可扩展性，则要害局部可能须要一些类图表白；又或者十分关注底层数据模型，则 E - R 图能够纳入思考范畴。
3 C4 模型实际中的决策和问题
连线表白依赖关系还是数据流向？
都能够，C4 模型中的连线既能够表白依赖方向，也能够表白数据流向。原则上，设计人员须要保障其清晰且无歧义。实际中个别通过正当的文字说明来明确的表白元素间的关系。
Jar 或类库应该建模为“容器”？“组件”？
Jar 包或类库个别是链接到调用方的过程中，作为过程中的一部分存在，这种依赖个别不示意为容器，而是组件。当然，是否要将 Jar，比方 SDK 示意为组件并体现在组件图上须要设计人员具体情况具体分析。
数据存储系统应该建模为“软件系统”还是“容器”？
数据存储系统，比方 MySQL、DFS 等个别是作为独立的内部存储集群存在，集群的运维可能归属于公司的运维团队。以 OSS 为例，但从利用角度而言，即便集群的运维不归属以后开发团队，团队也会申请租户隔离的专属空间，因而，在 C4 模型中这种状况应该表述为“容器”。
音讯零碎应该如何建模？
音讯零碎个别作为两个容器间的交互媒介，因而在 C4 模型中音讯零碎的建模存在两种形式：
• 依赖音讯零碎的容器都显示与音讯零碎交互，明确的表白各自与音讯零碎的依赖关系或数据流向
• 屏蔽音讯零碎，只提现容器间的依赖关系，并对依赖进行明确阐明
图形化的过期问题
C4 模型自身也是一种文档化机制，同样也存在过期问题。只不过C4 模型通过对系统在不同的层级进行形象，每个形象层级的过期频率不同，由上到下逐步增大，上下文图的变动频率最小，而代码级则变动最大。
为什么 C4 不波及业务流、状态机、数据模型等建模
C4 模型仅对系统的动态构造进行建模，并不试图囊括或代替其它建模形式，C4 模型并不适宜所有维度的可视化表白。对于业务流能够基于 BPML、UML 流动图进行表白，状态机能够基于 UML 状态机图进行表白，而数据模型能够通过 E - R 图表白，不同建模语言互相补充。
4 零碎架构设计关注不同维度
作为架构师或零碎设计人员，在进行零碎架构设计时个别会关注不同维度，个别状况下，对于业务零碎建设而言，会关注以下维度。在架构设计（架构和设计）过程中，基于 C4 模型、UML 及 BPML 等多种建模形式互相补充，不同体现维度下能够采纳不同的建模形式
• 业务流程：泳道图或 UML 流动图，表白外围的业务流
• 业务用例、零碎用例：UML 用例图
• 畛域模型：UML 类图
• 零碎边界：C1，零碎上下文图
• 高层技术选型：C2，容器图
• 零碎职责调配：用线框图示意性能架构
• 要害局部的实现：C3，组件图
• 零碎要害的交互逻辑：UML 时序图
• 数据模型：E- R 图
• 要害实体的状态机：UML 状态机图
• 不同的高优先级架构属性的设计：比方，缓存计划、幂等性设计方案、定时工作弥补策略、降级限流策略等等，这些都与具体的需要所关注的高优先级的架构属性相干。
• 部署架构：UML 部署图
5 总结
软件架构设计的终极目标不在于设计自身，而在于架构设计用意的传播。图形化有助于在团队间进行高效的信息同步，但 不同的图形化形式在语义一致性和效率间存在均衡 。C4 模型通过不同的形象层级来表白零碎的动态构造，并提供了最小及的形象建模元素，为设计人员提供了一种 低认知负载、易于学习和应用 的高效的建模形式。在理论我的项目落地过程中，联合 C4 模型以及 UML、线框图等组合形式对架构设计进行可视化表白，肯定水平上可能晋升团队对架构设计认知的一致性以及建模效率。
作者：倪新明
