为什么需要C4结构设计，因为需要一个统一、简单的标准去可视化描述系统结构。
每一个人的大脑中，对系统的结构的抽象层次是不同的，所以我们可以定义一个标准去描述不同的纬度下，简洁的架构设计应该是什么样子的。
从上到下依次是系统System、容器Container、组件Component和代码Code
元素说明
关系——带箭头的线、元素——方块和角色、关系描述——线上的文字、元素的描述——方块和角色里的文字、元素的标记——方块和角色的颜色、虚线框。
通过在不同的抽象层次上，重新定义方块和虚线框的含义来将我们的表达限制在一个抽象层次上，从而避免在表达的时候产生抽象层次混乱的问题。
系统上下文图
在系统上下文图里，方块指代的是软件系统，蓝色表示我们聚焦的系统，也就是我开发的系统（也可能是我分析的系统，取决于我是谁），灰色表示我们直接依赖的系统，虚线框表示的是企业的边界。通过这些图形化的元素表达我们可以看出来各个系统彼此之间的关系
容器图
当我们放大一个系统，就会看到容器，如上图所示，C4模型认为系统是由容器组成的
个人认为，容器是C4模型最大的创举，尤其是在这个单体架构快速崩塌的时代
容器，既不是Docker的容器，也不是JavaEE里的容器，而是借用了进程模型，代指有自己独立进程空间的一种存在
组件图
当我们放大一个容器，我们就会看到组件，如上图所示。组件在这里面很好的把接口和它的实现类打包成一个概念来表达关系。我个人觉得有时候一些存在于代码中，但又不是接口的某些东西，比如Service、Controller、Repository之类也可以用组件图来表达
代码图
代码图没什么可说的，就是UML里的类图之类很细节的图。一般是不画的，都是代码生成出来。除非非常重要的且还没有写出代码的组件才画代码图
扩展图
系统景观图
系统景观图是比上下文图更丰富的系统级别的表达。不像上下文图只关注聚焦系统和它的直接关系，连一些间接相关的系统都会标示出来，那些系统的用户以及用户之间的关系也会标示出来，只是内部的用户会用灰色标记
动态图
动态图不同于其他表达静态关系的图，它是用来表达动态关系的，也就是不同的元素之间是如何调用来完成一个业务的。所以动态图不仅仅适用于一个层面上，它在系统级、容器级和组件级都可以画，表达的目标是不一样的
动态图关注数据
部署图
数据的同步、实例的数量都会影响部署图的内容。部署图基本都是容器级的，它能很好的表达出来容器到底部署了几个实例，部署在什么样的操作系统上，一个节点部署了几个容器之类，我们在实际使用中，发现需要考虑的信息太多，自己就抽象出了类似于亚马逊上实例规格的Small、Large之类的术语来表达机器配置，增进了开发和运维之间的交流准确性。
总结
在思维的世界里，我们都是盲人，很多东西我们以为自己知道，实际上画出来之后，才发现很多东西没想到，或者想的是乱的，同时别人也才可以给我们反馈