用于可视化软件体系结构的 C4 模型（转载）
介绍
要求建筑行业中的某人以视觉方式传达建筑物的架构，然后您将看到场地平面图，平面图，立面图，横截面图和细部图。相反，请软件开发人员使用图来交流软件系统的软件体系结构，您可能会感到混乱的盒子和线条……符号不一致（颜色编码，形状，线条样式等），命名不明确，未标记的关系，通用术语，缺少的技术选择，混合的抽象等。
作为一个行业，我们确实有统一建模语言（UML），ArchiMate和SysML，但是询问这些功能是否提供有效的软件架构通信方式通常是无关紧要的，因为许多团队已经将它们抛弃了，希望使用更简单的“盒子和线”图。放弃这些建模语言是一回事，但也许在争夺敏捷性的竞赛中，许多软件开发团队已经失去了可视化交流的能力。
您的代码图
创建C4模型是为了帮助软件开发团队在前期设计会议和回顾性文档化现有代码库时描述和交流软件体系结构。这是一种以各种细节级别创建代码映射的方法，就像您使用Google Maps之类的工具来放大或缩小您感兴趣的区域一样。
像源代码一样，Google街景视图提供了一个非常底层且准确的位置视图。
如果缩小，在陌生的环境中导航会变得更加容易。
进一步缩小将提供您可能尚未意识到的其他上下文。
不同的缩放级别可让您向不同的受众讲述不同的故事。
尽管C4模型主要针对软件架构师和开发人员，但它为软件开发团队提供了一种有效且有效地交流其软件体系结构的方法，该方法可以进行不同级别的详细说明，在进行前期设计或追溯时向不同类型的受众讲述不同的故事。记录现有代码库。
级别1：系统上下文图提供了一个起点，显示了范围内的软件系统如何适应其周围环境。
级别2：容器图放大了范围内的软件系统，显示了高级技术构建块。
级别3：组件图放大单个容器，显示其中的组件。
级别4：代码（例如UML类）图可用于放大单个组件，显示该组件的实现方式。
不同的缩放级别可让您向不同的受众讲述不同的故事。
C4模型是一种“抽象至上”的软件体系结构图方法，它基于反映软件设计师和开发人员如何思考和构建软件的抽象。少量的抽象和图表类型使C4模型易于学习和使用。
好的软件架构图的重要性
良好的软件架构图可帮助沟通（在软件开发/产品团队内部和外部），新员工入职，风险识别（例如，风险风暴），威胁建模（例如STRIDE和LINDDUN）等。良好的软件架构图表有助于使每个人对所构建软件的理解保持一致，从而有助于提高团队效率。
抽象
为了创建这些代码映射，我们首先需要一组通用的抽象来创建一种无处不在的语言，我们可以用它来描述软件系统的静态结构。C4模型从容器，组件和代码的角度考虑软件系统的静态结构。和人们使用的软件系统，我们建立。
一个软件系统由一个或多个容器（Web应用程序，移动应用程序，桌面应用程序，数据库，文件系统等）组成，每个容器包含一个或多个组件，这些组件又由一个或多个代码元素实现（例如类，接口，对象，函数等）。
示例软件体系结构模型的可视化，显示了组成静态结构的元素的层次结构。
人
一个人代表您的软件系统的人类用户之一（例如，参与者，角色，角色等）。
软件系统
软件系统是最高级别的抽象，它描述了一些可以为用户带来价值的东西，无论他们是不是人类。这包括您正在建模的软件系统，以及该软件系统所依赖的其他软件系统（反之亦然）。在许多情况下，一个软件系统是由一个软件开发团队“拥有”的。
容器
不是Docker！在C4模型中，容器代表应用程序或数据存储。为了使整个软件系统正常工作，必须运行一个容器。实际上，容器类似于：
服务器端Web应用程序：在Apache Tomcat上运行的Java EE Web应用程序，在Microsoft IIS上运行的ASP.NET MVC应用程序，在WEBrick上运行的Ruby on Rails应用程序，Node.js应用程序等。
客户端网络应用程序：使用Angular，Backbone.JS，jQuery等在网络浏览器中运行的JavaScript应用程序。
客户端桌面应用程序：使用WPF编写的Windows桌面应用程序，使用Objective-C编写的OS X桌面应用程序，使用JavaFX编写的跨平台桌面应用程序等。
行动应用程式：Apple iOS应用程式，Android应用程式，Microsoft Windows Phone应用程式等。
服务器端控制台应用程序：独立（例如“ public static void main”）应用程序，批处理等。
微服务：一个微服务，在任何托管从传统的Web服务器，像春天开机，Dropwizard等。
无服务器功能：单个无服务器功能（例如，Amazon Lambda，Azure函数等）。
数据库：关系数据库管理系统，文档存储，图形数据库等中的模式或数据库，例如MySQL，Microsoft SQL Server，Oracle数据库，MongoDB，Riak，Cassandra，Neo4j等。
Blob或内容存储库：Blob存储库（例如Amazon S3，Microsoft Azure Blob存储等）或内容交付网络（例如Akamai，Amazon CloudFront等）。
文件系统：完整的本地文件系统或较大的网络文件系统的一部分（例如，SAN，NAS等）。
Shell脚本：用Bash等编写的单个Shell脚本。
等等
容器本质上是一个上下文或边界，在其中执行一些代码或存储一些数据。每个容器都是一个可单独部署/运行的事物或运行时环境，通常（但并非总是）在其自己的进程空间中运行。因此，容器之间的通信通常采用进程间通信的形式。
零件
“组件”一词在软件开发行业中是一个非常繁重的术语，但是在这种情况下，组件是封装在定义良好的接口后面的一组相关功能。如果您使用的是Java或C＃之类的语言，则想到组件的最简单方法是它是接口后面的实现类的集合。诸如如何打包这些组件（例如，一个组件与每个JAR文件，DLL，共享库等的多个组件）的打包方式是一个单独且相互关注的问题。
这里要注意的重要一点是，容器内的所有组件通常都在同一处理空间中执行。 在C4模型中，组件不是可单独部署的单元。
核心图
然后，通过创建Context，Container，Component和（可选）代码（例如UML类）图的集合来可视化此抽象层次结构。这就是C4模型的名称。
参见示例图，键和叙述
级别1：系统上下文图
系统上下文图是用于绘制和记录软件系统的一个很好的起点，使您可以退一步来查看大图。绘制一个图表，将您的系统显示为一个中心的方框，周围是用户和与之交互的其他系统。
这里的细节并不重要，因为这是您的缩小视图，显示了系统概况。重点应该放在人员（角色，角色，角色等）和软件系统上，而不是技术，协议和其他低级细节上。您可以向非技术人员展示这种图表。
范围：单个软件系统。
主要元素：范围内的软件系统。
支持元素：在范围内直接连接到软件系统的人员（例如，用户，参与者，角色或角色）和软件系统（外部依存关系）。通常，这些其他软件系统不在您自己的软件系统的范围或边界之内，因此您不承担任何责任或所有权。
目标受众：软件开发团队内部和外部的所有人，包括技术人员和非技术人员。
参见示例图，键和叙述
第2级：容器图
了解了系统如何适应整个IT环境后，下一步真正有用的操作就是使用“容器图”放大系统边界。“容器”类似于服务器端Web应用程序，单页面应用程序，桌面应用程序，移动应用程序，数据库架构，文件系统等。本质上，容器是可单独运行/可部署的单元（例如，单独的进程空间） ）来执行代码或存储数据。
容器图显示了软件体系结构的高层结构以及如何在其间分配职责。它还显示了主要的技术选择以及容器之间的通信方式。这是一个简单的，以技术为重点的高级图表，对软件开发人员和支持/操作人员都非常有用。
范围：单个软件系统。
主要元素：范围内软件系统内的容器。
支持元素：直接连接到容器的人员和软件系统。
目标受众：软件开发团队内部和外部的技术人员；包括软件架构师，开发人员和运营/支持人员。
注意：此图未说明部署方案，集群，复制，故障转移等。
参见示例图，键和叙述
级别3：组件图
接下来，您可以放大并进一步分解每个容器，以识别主要的结构构件及其相互作用。
组件图显示了容器如何由多个“组件”组成，每个组件是什么，它们的职责以及技术/实施细节。
范围：单个容器。
主要元素：范围内的容器中的组件。
支持元素：容器（在范围内的软件系统内）以及直接连接到组件的人员和软件系统。
目标受众：软件架构师和开发人员。
参见示例图和叙述
级别4：代码
最后，您可以放大每个组件以显示如何将其实现为代码。使用UML类图，实体关系图或类似的图。
这是可选的详细级别，通常可以从IDE等工具中按需获得。理想情况下，此图将使用工具（例如，IDE或UML建模工具）自动生成，并且您应考虑仅显示那些允许您讲述您要讲述的故事的属性和方法。除了最重要或最复杂的组件外，不建议使用此级别的细节。
范围：单个组件。
主要元素：作用域内组件内的代码元素（例如，类，接口，对象，函数，数据库表等）。
目标受众：软件架构师和开发人员。
补充图
一旦对静态结构有了很好的了解，就可以补充C4图以显示其他方面。
系统格局图
C4模型提供单个软件系统的静态视图，但是在现实世界中，软件系统永远不会孤立存在。因此，尤其是在您负责一组软件系统时，了解所有这些软件系统如何在企业范围内融合在一起通常很有用。为此，只需添加另一个C4图“顶部”的图，以从IT角度显示系统格局。像系统上下文图一样，该图可以显示组织边界，内部/外部用户和内部/外部系统。
本质上，这是企业级软件系统的高级映射，其中每个感兴趣的软件系统都有C4向下钻取。从实践的角度来看，系统格局图实际上只是系统上下文图，而没有特别关注特定的软件系统。
适用范围：企业。
主要元素：范围内与企业相关的人员和软件系统。
目标受众：软件开发团队内部和外部的技术人员和非技术人员。
动态图
当您想显示静态模型中的元素如何在运行时进行协作以实现用户故事，用例，功能等时，动态图可能很有用。该动态图基于UML通讯图 （以前称为“ UML”协作图”）。它类似于UML序列图， 但是它允许带有编号的交互作用的图元素的自由形式排列以指示顺序。
范围：企业，软件系统或容器。
主要和辅助元素：取决于图的范围；企业（请参阅系统架构图），软件系统（请参阅系统上下文或容器图），容器（请参阅组件图）。
目标受众：软件开发团队内部和外部的技术人员和非技术人员。
部署图
部署图使您能够说明如何将静态模型中的容器映射到基础结构。此部署图基于UML部署图，尽管略微简化以显示容器和部署节点之间的映射。部署节点类似于物理基础架构（例如物理服务器或设备），虚拟化基础架构（例如IaaS，PaaS，虚拟机），容器化基础架构（例如Docker容器），执行环境（例如数据库服务器，Java EE）。 Web /应用程序服务器，Microsoft IIS）等。部署节点可以嵌套。
您可能还希望包括基础结构节点，例如DNS服务，负载平衡器，防火墙等。
范围：单个软件系统。
主要元素：范围内软件系统内的部署节点和容器。
支持元素：在软件系统部署中使用的基础结构节点。
目标受众：软件开发团队内部和外部的技术人员；包括软件架构师，开发人员，基础架构设计师和运营/支持人员。
符号
C4模型没有规定任何特定的符号。以下是一种适用于白板，纸张，便签，索引卡和各种绘图工具的简单表示法。
人
软件系统
容器
零件
关系
然后，您可以使用颜色和形状来补充图，以添加其他信息，或者只是使图更美观。
C4和UML
尽管上面的示例图是使用“框和线”表示法创建的，但可以使用UML并适当使用包，组件和构造型来说明核心图。但是，最终的UML图确实缺少相同程度的描述性文本，因为使用某些UML工具无法（或不容易）添加此类文本。
这是用于比较的系统上下文，容器和组件图的三个示例。
系统上下文图
容器图
组件图
C4和ArchiMate
有关如何使用ArchiMate创建C4模型图的详细信息，请参见C4模型，体系结构观点和Archi 4.7。
图键/图例
所使用的任何符号都应尽可能自我描述，但所有图表均应具有使符号明确的键/说明。这也适用于使用UML，ArchiMate和SysML等符号创建的图，因为不是每个人都知道使用的符号。
记法，记法，记法
尽管C4模型是一种抽象优先方法，并且与表示法无关，但是您仍然需要确保您的图表示法有意义，并且图是可理解的。考虑这一点的一种好方法是问自己是否每个图表都可以独立存在，并且（大多）无需叙述即可理解。您可以使用此简短的软件体系结构图审阅清单来提供帮助。
这是与符号有关的一些建议。
图表
每个图应具有描述图类型和范围的标题（例如，“我的软件系统的系统上下文图”）。
每个图都应该有一个键/注释，说明要使用的符号（例如，形状，颜色，边框样式，线型，箭头等）。
首字母缩写词和缩写（业务/领域或技术）应为所有读者所理解，或在图表键/图例中进行解释。
元素
应该明确指定每个元素的类型（例如，人员，软件系统，容器或组件）。
每个元素都应有简短的描述，以提供“一目了然”的关键职责视图。
每个容器和组件都应具有明确指定的技术。
人际关系
每条线应代表一个单向关系。
每行都应加标签，标签应与关系的方向和意图一致（例如，依赖性或数据流）。尝试使标签尽可能具体，最好避免使用单个单词，例如“用途”。
容器之间的关系（通常表示容器之间的通信）应具有明确标记的技术/协议。
例子
这是基于C4模型的示例软件体系结构图的一些集合。
Big Bank plc
（系统格局，系统上下文，容器，组件，动态和部署）
金融风险系统
（系统环境）
Spring PetClinic
（系统上下文，容器，组件，动态和部署）
消息总线和微服务
（容器和动态）
Widgets Limited
（系统格局，系统上下文和动态）
Contoso大学
（系统上下文，容器，组件和动态）
经常问的问题
C4模型的背景是什么？
C4模型是由西蒙·布朗（Simon Brown）创建的，西蒙·布朗（Simon Brown）在伦敦担任软件开发人员/架构师时开始教人们有关软件架构的知识。西蒙培训课程的一部分是设计练习，其中要求一群人提出一些要求，要求他们做一些设计，并绘制一些图表来表达该设计。
尽管这是一个以设计为重点的练习，但是各种各样的图表使人们很清楚地看到，想法的可视化是大多数人非常缺乏的一项技能。C4模型本质上是Simon过去如何可视化软件体系结构的形式化，这已经发展了多年。
C4模型背后的灵感是什么？
C4模型的灵感来自统一建模语言和软件架构的4 + 1模型。总而言之，您可以将C4模型视为基础概念的简化版本，旨在（1）使软件开发人员更容易描述和理解软件系统的工作方式，以及（2）最小化软件之间的差距。架构模型/说明和源代码。
C4模型的根源以及其中的各种图表类型都可以追溯到2006年左右的某个地方，尽管“ C4”这个名称出现的时间要晚得多，大约在2011年底。受敏捷运动影响的团队并不热衷于使用UML。
C4模型不是倒退了一步吗？您为什么要重新发明UML？为什么不只使用UML？
您是将C4模型视为前进还是后退取决于您所处的位置。如果您使用的是UML（或SysML，ArchiMate等），并且对您有用，请坚持使用。不幸的是，UML的使用率似乎在下降，许多团队已恢复到再次使用临时框和折线图。鉴于许多团队不想使用UML（出于各种原因），C4模型有助于在通信软件体系结构的方式中引入一些结构和纪律。对于许多团队来说，C4模型就足够了。对于其他人，也许这是UML的垫脚石。
有多少人使用C4模型？
诚实的答案是没人知道。西蒙亲自为30多个国家的10,000多人教授了C4模型。会议演讲，视频，书籍和文章的意义远不止于此。其他人也在教，说和写C4模型。但是，从初创公司到全球家喻户晓的组织，肯定会使用它。
为什么是“容器”？
诸如“过程”，“应用程序”，“应用程序”，“服务器”，“可部署单元”之类的术语都具有相关含义，因此选择名称“容器”作为描述组件所处事物的通用方式。从一个角度来看，不幸的是，容器化已变得流行，因为许多软件开发人员现在将“容器”一词与Docker关联了。但是从另一个角度来看，C4模型中的容器与基础结构（例如Docker）容器之间有时存在很好的奇偶校验。
尽管许多团队照原样成功使用了C4模型，但可以根据需要随时更改术语。
我们可以更改术语吗？
此术语（上下文，容器，组件和代码）适用于许多组织和多种类型的软件。但是，有时组织会具有人们已经熟悉的现有术语。也许“组件”和“类”不容易映射到所使用的技术（例如，功能语言经常使用术语“模块”和“功能”）。
随意修改用于描述不同抽象级别的软件体系结构的术语。只要确保每个人都明确理解它即可。
您如何建模微服务和无服务器？
广义上讲，使用C4模型时，有两种方法可以绘制微服务图。
将微服务作为软件系统：如果您的软件系统依赖于您无法控制的许多微服务（例如，它们由单独的团队拥有和/或操作），则将这些微服务建模为您无法将其建模为外部软件系统看到里面。
将微服务作为容器：另一方面，如果微服务是您正在构建的软件系统的一部分（即您拥有它们），则将它们建模为容器以及这些微服务使用的任何数据存储。与模块化单片应用程序是在其中运行许多组件的容器一样，微服务只是在其中运行（较少）组件的容器。
无服务器功能/ lambdas / etc也是如此。根据所有权将它们视为软件系统或容器。
您如何绘制大型和复杂的软件系统？
即使使用相对较小的软件系统，也很容易尝试将整个故事包含在单个图表中。例如，如果您有一个Web应用程序，则创建一个单一的组件图以显示构成该Web应用程序的所有组件似乎是合乎逻辑的。除非您的软件系统真的那么小，否则您可能会在图表画布上用尽空间，或者发现很难发现不会被无数重叠线条所困扰的布局。使用较大的图表画布有时会有所帮助，但由于认知负担过大，通常很难解释和理解大型图表。如果没有人理解该图，则没人会去看它。
取而代之的是，不要害怕将单个复杂的图分解为大量的简单图，每个图都围绕业务领域，功能领域，功能分组，有界上下文，用例，用户交互，功能集等进行特定的关注。关键是要确保每个单独的图都以相同的抽象水平讲述同一总体故事的不同部分。
另请参见图表与建模。
图表会很快过时吗？
由于C4模型的层级性质，每个图将以不同的速率变化。
系统上下文图：在大多数情况下，系统上下文图的变化非常缓慢，因为它描述了软件系统所处的环境。
容器图：除非您要构建大量使用微服务或无服务器lambda / functions / etc的软件系统，否则容器图的变化也将相对缓慢。
组件图：对于正在积极开发的任何软件系统，随着团队将代码添加，删除或重组为具有凝聚力的组件，组件图可能会经常更改。使用工具自动生成此详细信息级别可能会有所帮助。
代码图：如果代码库正在积极开发中，那么4级代码（例如类）图可能很快就会过时。因此，建议不要（1）完全不要创建它们，或者（2）使用IDE等工具按需生成它们。
为什么C4模型不涵盖业务流程，工作流，状态机，域模型，数据模型等？
C4模型的重点是构成软件系统的静态结构，处于不同的抽象级别。如果需要描述其他方面，请随时用UML图，BPML图，ArchiMate图，实体关系图等对C4图进行补充。
C4模型与UML，ArchiMate和SysML？
尽管已经存在UML，ArchiMate和SysML等现有符号，但许多软件开发团队似乎并未使用它们。通常是因为团队对这些符号了解得不够充分，认为它们过于复杂，认为它们与敏捷方法不兼容或没有所需的工具。
如果您已经成功使用这些表示法之一来传达软件体系结构并且该软件可以正常工作，请坚持使用。如果不是，请尝试使用C4模型。并且，如果需要，不要害怕用UML状态图，时序图等来补充C4图。
我们可以结合使用C4和arc42吗？
是的，许多团队都这样做，并且C4模型与arc42文档模板兼容，如下所示。
上下文和范围=>系统上下文图
Building Block视图（级别1）=>容器图
Building Block视图（级别2）=>组件图
Building Block视图（级别3）=>类图
C4模型是否暗示设计过程或团队结构？
一个常见的误解是，团队的设计过程应遵循C4模型层次结构中的级别，也许团队中的不同人员负责不同级别的图表。例如，业务分析师创建系统上下文图，架构师创建容器图，而开发人员则负责其余的细节级别。
尽管您当然可以通过这种方式使用C4模型，但这不是预期或推荐的使用模式。C4模型只是从不同抽象级别描述软件系统的一种方式，它对交付软件的过程没有任何暗示。
使用C4描述库，框架和SDK？
C4模型实际上是为在各种抽象级别上对软件系统建模而设计的。要记录库，框架或SDK，最好使用UML之类的方法。另外，您可以使用C4模型来描述框架，库或SDK的用法示例。也许使用颜色编码来表示定制的软件系统部分与为您提供的部分。
网络应用；一两个容器？
如果您正在构建主要生成静态HTML内容的服务器端Web应用程序（例如Spring MVC，ASP.NET，Ruby on Rails，Django等），则该容器为单个容器。如果服务器端Web应用程序（例如，使用Angular构建的单页应用程序）传递了大量JavaScript，则这是两个容器。 这是一个例子。
尽管在部署时，服务器端Web应用程序同时包含服务器端代码和客户端代码，但是将客户端和服务器视为两个单独的容器使它很明显，它们是两个单独的进程空间，它们之间通过进程间进行通信/远程通信机制（例如JSON / HTTPS）。它还为分别放大每个容器以显示其中的组件提供了基础。
这些行应该代表依赖关系还是数据流？
这是您的选择。有时图表能更好地显示依赖关系（例如使用，读取等），有时数据流（例如客户更新事件）会更好。无论选择哪种方式，请确保线条的描述与箭头的方向匹配。
还值得记住的是，大多数关系都可以用任何一种方式来表达，并且越明确，越好。例如，将关系描述为“将客户更新事件发送到”比简单地“客户更新事件”更具描述性。
Java JAR，C＃程序集，DLL，模块等是容器吗？
通常不会。容器是运行时构造，例如应用程序。而Java JAR文件，C＃程序集，DLL，模块等则用于在这些应用程序中组织代码。
Java JAR，C＃程序集，DLL，模块，包，名称空间，文件夹等是组件吗？
也许但是，再次，通常不是。C4模型用于显示运行时单元（容器）以及功能如何在它们之间进行分区（组件），而不是组织单元，例如Java JAR文件，C＃程序集，DLL，模块，包，名称空间或文件夹结构。
当然，这些构造和组件之间可能存在一对一的映射。例如，如果您要构建六角形体系结构，则可以为每个组件创建一个Java JAR文件或C＃组件。另一方面，可能使用多个JAR文件中的代码来实现单个组件，这通常是当您开始考虑第三方框架/库以及它们如何嵌入到代码库中时发生的情况。
您是否应该包括消息总线，API网关，服务网格等？
如果您有两个服务A和B，它们通过消息总线（与主题，队列，p2p，pub / sub等无关）或其他中介（例如，API网关或服务网格）发送消息进行通信，则可以几个选择。第一种选择是显示服务A向中介发送消息，中介随后将该消息转发给服务B。虽然准确，但该图的“中枢和分支”性质倾向于掩盖消息之间存在耦合的概念。生产者和消费者。
另一种方法是忽略中介，而使用符号（例如，文字说明，颜色编码，线条样式等）表示服务A和B之间的交互是通过中介发生的。这种方法往往会使图表讲得更清楚。
数据存储服务应显示为软件系统还是容器？
一个常见问题是，是否应将Amazon S3，Amazon RDS，Azure SQL数据库，内容交付网络等服务显示为软件系统或容器。毕竟，这些是我们大多数人都不拥有或自己运营的外部服务。
如果您要构建使用Amazon S3来存储数据的软件系统，那么您确实没有自己运行S3，但是您确实对所使用的存储桶拥有所有权和责任感。与Amazon RDS类似，您（或多或少）可以完全控制创建的任何数据库架构。出于这个原因，尽管它们是在其他位置托管的，但由于它们是软件体系结构的组成部分，因此请将它们视为容器。
C4模型是否普遍适用？
C4模型旨在帮助描述，记录和绘制定制的定制软件系统。从这个角度来看，C4模型可用于描述以各种编程语言构建，部署在各种平台（本地或云）上的各种软件体系结构（整体式或分布式）。
可能不太适合C4模型的解决方案包括嵌入式系统/固件，以及需要大量定制而不是定制开发的解决方案（例如SAP和Salesforce）。即使有了这些解决方案，您仍然可能会发现系统上下文图和容器图很有用。
图表与建模
作为一个行业，我们倾向于使用图表而不是建模，这主要是因为进入的门槛相对较低，而且这被视为一项简单得多的任务。进行图表绘制时，通常会使用不了解任何图表语义的工具（例如Microsoft Visio或白板）创建一个或多个单独的图表（通常带有临时符号）。图表工具的领域语言实际上只是盒子和线条，因此您不能向他们问诸如“组件X有哪些依赖关系？”之类的问题。此外，跨图重复使用图元素通常是通过复制（即复制和粘贴）来完成的，因此，您有责任在重命名此类元素时使图保持同步。在这里值得注意的是，无论您要进行制图还是建模，都可以使用C4模型，但是当您从制图过渡到建模时，会有一些有趣的机会。
通过建模，您将建立某种事物的非可视模型（例如，软件系统的软件体系结构），然后在该模型之上创建不同的视图（例如，图）。这需要更多的严格性，但是结果是所有元素及其之间关系的单一定义。反过来，这又允许建模工具理解您要执行的操作的语义，并在模型之上提供其他智能。它还允许建模工具自动提供替代的可视化效果。
上面常见的问题之一是有关绘制大型复杂软件系统的图。一旦在图上开始有超过20个元素（以及它们之间的关系），生成的图就会开始变得非常混乱。例如，图像1（下图）是单个容器的组件图。
解决此问题的一种方法是不在单个图上显示所有组件，而是创建多个图，每个“切片”通过容器创建一个图（下图2）。这种方法当然可以提供帮助，但是值得一问的是，结果图是否有用。您将要使用它们，如果要使用它们，您将用于什么用途？尽管“系统上下文”图和“容器”图非常有用，但是大型软件系统的组件图的价值通常较低，因为它们很难保持最新状态，并且您可能会发现很少有人看它们，特别是如果不包括它们在文档或演示文稿中。
一旦图表上有超过20个元素，图表就会很快变得混乱。
创建多个图（每个“切片”一个）可能会有所帮助，尽管生成的图往往非常简单，并且会增加使它们保持最新状态所需的工作。
除了创建图表之外，您还可以使用其他可视化方法。该可视化显示了容器内部组件之间的依赖关系。
这种替代的可视化显示了模型中的所有元素和关系，并对其进行过滤以显示模型的子集。
通常，图本身并不是最终目标，团队使用图来回答他们所遇到的其他问题，例如“组件X有哪些依赖关系？”。在这种情况下，构建模型将使您能够回答此类问题，而无需花费额外的精力来创建图表。换句话说，一旦有了模型，就可以通过多种不同方式对其进行可视化处理（上图3和图4），从而有助于回答您要回答的实际问题。图当然是交流软件体系结构的一种绝妙方法，但是其他可视化有时可以帮助回答您可能遇到的真正的潜在问题。
还未添加个人签名 2019.03.25 加入
还未添加个人简介
评论