京东云开发者｜软件架构可视化及C4模型：架构设计不仅仅是UML( 二 ) _生活百科

文章插图
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模型中消息系统的建模存在两种方式：
?依赖消息系统的容器都显示与消息系统交互，明确的表达各自与消息系统的依赖关系或数据流向?屏蔽消息系统，只提现容器间的依赖关系，并对依赖进行明确说明图形化的过期问题