提示7-2：解释硬件和基础设施决策！ #deployment-view #mapping部署或基础设施图支持对底层硬件的总体理解。 除了这个概述外，了解硬件决策背后的原因、特定机器、处理器或其他设备的选择也是有用的。 如果硬件在架构中发挥着重要作用，您甚至可以为此目的使用节点模板，类似于下表： 节点<节点名称> 责任 这个硬件元素的作用是什么，它在做什么？ （技术）特征 即cpus/内核、内存、吞吐量、端口nr、供应商、型号… 相关构 ...

提示7-3：记录各种环境！ #deployment-view 如果系统是在不同的硬件环境中开发、测试和运行的（即开发用于开发的DEV，用于构建/集成的CI，用于系统和手动测试的TEST以及用于生产的PROD），您应该记录这些环境以及它们之间可能存在的差异。 刻板印象“执行环境”象征着这样的环境。右下角（即在开发中）的小“无限”符号意味着有一个精致的图表（“无限”符号是Sparx EnterpriseArchitect®的专长）。 ...

提示7-4：分层记录部署视图！ #deployment-view #hierarchy 就像在构建块视图中一样（见提示5-2（分层构建块视图）），您可以将部署视图组织并记录为层次结构。这在异构或分布式系统中特别有用。 下图给出了一个示例： ...

提示12-1：认真对待术语表！ #glossary #essential 您应该确保所有参与者对他们在系统上下文中使用的重要业务（和技术）术语有共同的理解。 术语表是“显式胜于隐含”一般规则的一种表现。 ...

提示12-3：用（图形）模型修改术语表！ #glossary 您可以在图表中解释重要术语的关系，并使用该图表作为文本解释或定义的基础。 您在下面找到一个示例（取自开源项目“HtmlSanityCheck”）： （在示例中，我们跳过了带有正确定义的表格-我们非常确定您可以想象它应该是什么样子……） ...

提示3-12：在上下文中显示外部影响！ #context 您的系统可能需要处理对外部系统的不同类型的依赖，例如： 数据或信息依赖性 时间依赖性 局部或空间依赖性 硬件依赖性 对个人、组织或角色的依赖 传递（间接）依赖关系 通常，您只会在域上下文中显示用户角色和数据/信息依赖性。然而，有时其他类型的依赖项对您的系统也很重要。这种依赖性可以在图表本身或附加解释中描述。 下图显示了一个示例：用户在使用系统之前必须注册（步骤1），系统命令短信（步骤2），外部短信提供商通 ...

提示3-13：在上下文中显示传递依赖项！ #context 系统有时具有间接（传递）依赖性，这些依赖性可能与一些利益相关者的沟通有关。在您的上下文中包括这些依赖项。下图显示了一个例子：依赖项3和6以及左上角的注册办公室是间接的。 注意：上下文中的传递依赖项与经济性规则相矛盾（因为您通过显示传递依赖性来获得额外的元素）。因此，您只有在有必要了解实际情况时才应该描述它们。 ...

提示3-9：显示全部（全部！）外部接口！ #context #external-interface #essential 追求完整性（通常）是个坏主意我们认为，试图实现完整性通常是一个坏主意，因为它会带来很多努力，特别是为了实现（总是）缺少的5%…… 但是：显示所有外部类别有一个（至少）例外：您应该将所有（如每个）外部系统包含在上下文图中。为了省力，您可以创建外部系统的类别、组或集群。 另请参阅提示3-7（集群类别）和提示3-8（带端口的集群））。 ...

提示7-8：解释你的节点！ #deployment-view #hardware 您的几个节点（即硬件元素、处理器、服务器、容器、虚拟机、防火墙、负载均衡器等）对系统具有高度重要性或特殊意义。 在这种情况下，您应该解释这些节点，有哪些属性，以及为什么它们对系统或其操作如此特殊。 arc42模板（第7节）包含标有“基础设施元素”的子部分-您可以使用这些子部分来记录或指定此类详细信息。 ...

提示7-9：解释什么（其他）与系统的生产使用（又称操作）相关！ #deployment-view 将系统投入生产的挑战除了编译、集成和测试（又称构建）系统外，还需要完成其他任务，才能在目标平台上启动和运行任何足够复杂的系统： 我们不想吓到你-但想展示一些你（可能）需要考虑的活动示例： 确保安装了正确的操作系统（版本+补丁） 创建所需的（用户）帐户，以及适当的访问权限 在目标操作系统上创建目录，以及适当的访问权限 创建和配置数据库，包括所需的数据库帐户和访问权限 迁移现有的应 ...