| layout | title |
|---|---|
doc |
常见问题 |
C4模型由Simon Brown创建，他在担任软件开发人员/架构师期间开始教授软件架构。Simon的培训课程的一部分是一个设计练习，参与者被给出一些需求，要求进行设计，并绘制一些图表来表达该设计。
尽管这是一个以设计为中心的练习，但各种各样的图表使得人们显而易见地缺乏可视化表达想法的技能。C4模型本质上是Simon过去用来可视化软件架构的方法的形式化表达，并且随着时间的推移不断演变。
确切的日期很难确定，但C4模型的根源可以追溯到2006-2009年之间，图表类型（“上下文”、“容器”、“组件”、“类”）在2010年初被命名，“C4”名称在2011年初首次使用。第四种图表类型在2015-2016年间从“类”重命名为“代码”。
C4模型诞生于一个受敏捷运动影响的团队不太热衷于使用统一建模语言 (UML)来记录软件架构的时期，即使他们在创建图表。尽管如此，C4模型的灵感来自UML和4+1软件架构视图模型。总之，你可以将C4模型视为基础概念的简化版本，旨在(1)使软件开发人员更容易描述和理解软件系统的工作原理，以及(2)尽量缩小软件架构模型/描述与源代码之间的差距。
C4模型的重点是构成软件系统的静态结构，在不同的抽象层次上。如果你需要描述其他方面，可以随意补充C4图表，使用UML图表、BPML图表、ArchiMate图表、实体关系图等。
一个常见的误解是团队的设计过程应该遵循C4模型层次结构中的各个层次，或许团队中的不同人员负责不同层次的图表。例如，业务分析师创建系统上下文图，架构师创建容器图，而开发人员负责其余的详细层次。
C4模型实际上是为了在各种抽象层次上对软件系统进行建模而设计的。要记录库、框架或SDK，你可能更适合使用UML之类的东西。或者，你可以使用C4模型来描述你的框架、库或SDK的使用示例；也许可以使用颜色编码来表示软件系统中哪些部分是定制的，哪些是为你提供的。
C4模型旨在帮助描述、记录和绘制定制构建的软件系统。从这个角度来看，C4模型可以用来描述各种软件架构（单体或分布式），使用各种编程语言构建，部署在各种平台上（本地或云端）。
可能不太适合C4模型的解决方案包括嵌入式系统/固件，以及依赖于大量定制而不是定制开发的解决方案（例如SAP和Salesforce）。即使对于这些解决方案，你仍然可能会发现系统上下文和容器图有用。
示例图表方便地包含少量的框和箭头，但你可能会问C4模型如何用于现实世界的软件系统，其中有600个组件而不是6个。 答案是你选择的工具可以帮助或阻碍你。
即使是相对较小的软件系统，也很容易尝试在单个图表上包含整个故事。 例如，如果你有一个Web应用程序，似乎逻辑上应该创建一个显示组成该Web应用程序的所有组件的单一组件图。除非你的软件系统真的那么小，否则你可能会在图表画布上没有足够的空间，或者发现很难找到一个不被大量重叠线条所混乱的布局。有时使用更大的图表画布可以有所帮助，但大型图表通常难以解释和理解，因为认知负荷太高。如果没有人理解图表，就没有人会看它。
相反，不要害怕将单个复杂图表拆分为更多的简单图表，每个图表围绕业务领域、功能区域、功能分组、边界上下文、用例、用户交互、功能集等具有特定的焦点。关键是确保每个单独的图表在相同抽象层次上讲述同一整体故事的不同部分。
这是一个显示由多个微服务组成的软件系统的容器图示例：
这个图表目前有效，但随着我们添加更多服务，它很快会变得混乱。作为一种替代方法，我们可以创建8个图表，每个图表专注于一个服务，显示最近的传入（入站）和传出（出站）依赖关系：
| Service 1 | Service 2 | Service 3 |
|---|---|---|
 |
 |
 |
这在使用绘图工具时很难做到，但在使用建模工具时却很简单——请参阅绘图与建模了解更多详细信息。这里的权衡是我们失去了“全局视图”。因此，另一种选择是创建一些替代的可视化，不像传统的“框和线”图那样冗长。同样，当你使用建模工具，并将软件架构模型视为可以以不同方式可视化的数据结构时，这相对简单。
| A | B |
|---|---|
 |
 |