好多年前 , 同事徐昊说过的一句话给了我很大启发 , 他说“纸上的不是架构 , 每个人脑子里的才是” 。这句话告诉我们 , 即便是天天工作在一个团队里的人 , 对架构的认识也可能是不一样的 。每个人嘴上说的是类似的话 , 但心里想象的画面仍然是不一样的 。在多年的工作中 , 我越来越认可这句话所揭示出的道理 。软件开发是一个团队协作的工作 , 混乱的理解会造成架构的无意义腐化、技术债的无意识积累、维护成本的无价值上升 。
最近听到一句话 , “那些精妙的方案之所以落不了地 , 是因为没有在设计上兼容人类的愚蠢” 。话糙理不糙 , 虽然最终人们选择的方案的思想都是在十年前甚至几十年前就已经存在的 , 然而在技术升级到足以“兼容”人类的愚蠢之前 , 这些思想只能在学术的故纸堆里睡大觉 。当然话糙确实也会有一个问题 , 将一个思想性问题转化成了情绪性问题 。人们容易把一些糟心的事情归因到人类的愚蠢 , 在宣泄完不满情绪后就停止思考了 。作为知识工作者 , 我们的思维不能停步 , 我们需要思考到底人类有哪些愚蠢 , 分别用什么方法去避免或者“兼容” 。
可以肯定彼此明明对自己开发的软件有不一样的认识却天天在一起讨论问题并试图把软件做好是一件愚蠢的事情 , 为了兼容这种愚蠢我们需要采用可视化的方法 。
为什么需要可视化呢 , 主要还是语言不靠谱 。人类语言真的是太随意了 , 只要你想 , 你可以说你见过一个方形的圆 , 并为此与别人辩论 。但是无论如何你也画不出来一个方形的圆 , 这就是我们需要可视化的原因 。
今天我们介绍一个工具 , 叫做C4 model , 这是我近几年见到的一个比较难得跟我的认知有大量共鸣的工具 。
该工具的作者在多年的咨询中经常发现 , 很多个人画出来的架构图都是不一样的 , 但也不是说谁画错了 , 而是每个人的抽象层次不一样 。抽象层次这种东西 , 说起来好像存在 , 但真要说清楚还挺难 , 于是作者类比地图 , 提出了缩放的概念 。(两年前我在教学生的时候提过同样的概念)如下图:
文章插图
上面的四张地图就是想说明 , 当我们看待真实世界的“架构图”时候 , 也是要不停的缩放 , 在每一个层次刻意忽略一些细节才能表达好当前抽象层次的信息 。所以他类比着把架构也提出了四个抽象层次:
文章插图
从上到下依次是系统System、容器Container、组件Component和代码Code 。(咦 , 那为什么叫C4呢 , 因为系统的图叫System Context , 系统上下文图 。为了凑四个C也是够拼的 。)
基于这四个层次的抽象 , C4模型由4张核心图和3张附属图组成 , 分别用于描述不同的场景 , 下面我们一一介绍一下 。
四张核心图系统上下文图
文章插图
如上图所示 , 这个图表达的是你所开发的系统和它的用户以及它所依赖的系统之间的关系 。从这个图上我们已经看出来C4图形的几个关键图形:
文章插图
C4说穿了就是几个要素:关系——带箭头的线、元素——方块和角色、关系描述——线上的文字、元素的描述——方块和角色里的文字、元素的标记——方块和角色的颜色、虚线框(在C4里面虚线框的表达力被极大的限制了 , 我觉得可以给虚线框更大的扩展空间) 。
通过在不同的抽象层次上 , 重新定义方块和虚线框的含义来将我们的表达限制在一个抽象层次上 , 从而避免在表达的时候产生抽象层次混乱的问题 。
那么在系统上下文图里 , 方块指代的是软件系统 , 蓝色表示我们聚焦的系统 , 也就是我开发的系统(也可能是我分析的系统 , 取决于我是谁) , 灰色表示我们直接依赖的系统 , 虚线框表示的是企业的边界 。通过这些图形化的元素表达我们可以看出来各个系统彼此之间的关系 。
推荐阅读
- 抢鲜!阿里架构师私藏并发编程笔记,公开前半段秒获8K标星
- 一文看懂网上支付系统架构
- Python数据分析之初识可视化
- 颠覆了我认知!阿里架构师原来是这样定义微服务、分布式构架的
- 大前端架构思考与选择
- 旅游类网页设计参考
- 6个顶级可视化Python库
- 工行“去O”数据库选型与分布式架构设计
- 语雀的技术架构演进之路
- LTE知识架构思维导图