容器图

文章插图
当我们放大一个系统 , 就会看到容器 , 如上图所示 , C4模型认为系统是由容器组成的 。我个人认为 , 容器是C4模型最大的创举 , 尤其是在这个单体架构快速崩塌的时代 。所谓容器 , 既不是Docker的容器 , 也不是JAVAEE里的容器 , 而是借用了进程模型 , 代指有自己独立进程空间的一种存在 。不管是在服务器上的单独进程空间 , 还是在浏览器里的单独进程空间 , 只要是单独的进程空间就可以看作一个容器 。当然如果你容器化做得好 , Docker的Container和这个Container可以一一对应 。有了这个概念的存在我们就可以更清晰的去表达我们的架构 , 而不是总是用一些模糊的东西 。
组件图

文章插图
【可视化架构设计——C4介绍】
当我们放大一个容器 , 我们就会看到组件 , 如上图所示 。组件在这里面很好的把接口和它的实现类打包成一个概念来表达关系 。我个人觉得有时候一些存在于代码中 , 但又不是接口的某些东西 , 比如Service、Controller、Repository之类也可以用组件图来表达 , 如果你学了一些没有明确抽象层次的架构知识或者一些单体时代的遗留经验的时候 , 你可以画出来一些组件图 , 来印证自己的理解 , 如下图 , 是我画的自己对DDD战术设计里面的一些概念的理解:

文章插图
比起模糊的堆砌在一起的文字 , 这种表达要清晰的很多 , 哪怕我的理解是不对的 , 也容易指出和讨论 。
代码图
代码图没什么可说的 , 就是UML里的类图之类很细节的图 。一般是不画的 , 都是代码生成出来 。除非非常重要的且还没有写出代码的组件才画代码图 。
以上就是C4的核心图 , 我们可以看到四种不同的抽象层次的定义会让我们更容易固定住我们讨论的层次 , 这点上我觉得C4是非常有价值的 。
三张扩展图架构设计设计要考虑的维度很多 , 仅四张核心图是不够的 , 所以作者又提供了三张扩展图 , 可以让我们关注更多的维度 。
系统景观图

文章插图
看得出来 , 系统景观图是比上下文图更丰富的系统级别的表达 。不像上下文图只关注聚焦系统和它的直接关系 , 连一些间接相关的系统都会标示出来 , 那些系统的用户以及用户之间的关系也会标示出来 , 只是内部的用户会用灰色标记 。
这个图有什么用呢?在我们分析一个企业的时候 , 我们需要一个工具帮助我们把一家公司给挖个底掉 , 做到完全穷尽 , 才能看到企业的全景图 , 从而理解局部的正确定位以做好局部设计为全局优化服务 。之前我试过以四色建模的红卡、事件风暴的事件两种工具来教人掌握这种能力 , 一般来说 , 程序员学员都无法快速掌握这种顺藤摸瓜的分析技巧 , 毕竟跟程序员的思维还是有些差异的 。但是用了系统景观图之后 , 学员就毫不费力的掌握了这种分析能力 , 所以我后来都是用这个图来教程序员探索企业的数字化全景图 , 效果极好 , 推荐给大家 。
动态图

文章插图
动态图不同于其他表达静态关系的图 , 它是用来表达动态关系的 , 也就是不同的元素之间是如何调用来完成一个业务的 。所以动态图不仅仅适用于一个层面上 , 它在系统级、容器级和组件级都可以画 , 表达的目标是不一样的 。
我之前曾经写过名为《像机器一样思考》的一系列文章 , 在文中也发明了类似的图 , 不同于本文中关系线上标注的是调用的方法、函数 , 我更关注的是数据 , 使用效果也很好 。
什么时候用动态图呢?举个小例子 , 我之前做一个内部的小系统 , 团队中只有一个有经验的工程师带着十多个毕业生 , 我便要求他们在开始工作之前都画出动态图来 , 交由有经验的工程师去评估他们的思路是否正确 , 如果有问题 , 就在开始之前就扼杀掉烂设计 。不管是毕业生还是初级工程师 , 改代码的能力都比写代码的能力要差很多 , 所以将烂设计扼杀在实现之前还是有帮助的 。
推荐阅读
- 抢鲜!阿里架构师私藏并发编程笔记,公开前半段秒获8K标星
- 一文看懂网上支付系统架构
- Python数据分析之初识可视化
- 颠覆了我认知!阿里架构师原来是这样定义微服务、分布式构架的
- 大前端架构思考与选择
- 旅游类网页设计参考
- 6个顶级可视化Python库
- 工行“去O”数据库选型与分布式架构设计
- 语雀的技术架构演进之路
- LTE知识架构思维导图
