构建逻辑架构：部署元素规划与架构验证

### 构建逻辑架构：部署元素规划与架构验证 在构建复杂的 IT 系统时，合理规划部署元素并验证架构的一致性至关重要。下面将详细介绍部署元素规划和架构验证的相关内容。 #### 1. 部署元素规划任务概述 部署元素规划任务的目的是确定待开发系统将部署的位置以及每个位置内的节点。任何中等复杂度的 IT 系统架构通常由多个不同的计算机平台组成，这些平台分布在一个或多个位置。这些位置可以是同一建筑物内的不同房间或楼层，也可以是不同地区甚至全球范围内的地理分布站点。 - **角色**：应用架构师（次要）、数据架构师（次要）、基础设施架构师。 - **输入**：架构决策（可选）、架构概述、架构概念验证（可选）、企业架构原则、现有 IT 环境（可选）、功能模型、功能需求、术语表、非功能需求、系统上下文。 - **输出**：部署模型。 - **步骤**： - 识别位置。 - 识别节点。 #### 2. 软件工程与系统工程的概念 系统工程领域认为系统由软件、硬件、信息和人员组成。在推导解决方案时，系统工程师会在软件、硬件和人员的使用上进行权衡。例如，如果性能是关键因素，可能会决定将某些系统元素在硬件中实现，而不是在软件或人员中实现。 系统工程特别关注将软件和硬件（以及人员）视为同等重要的部分，避免两种陷阱：一是将硬件视为软件的二等公民，仅仅作为执行软件的工具；二是将软件视为硬件的二等公民，仅仅作为使硬件按预期功能运行的工具。 #### 3. 识别位置步骤 在识别位置步骤中，需要审查相关的输入工作产品，以确定待开发系统将分布的位置。位置的识别基于对以下一个或多个工作产品的分析： - **架构决策**：可能建议在特定位置使用额外的可重用资产。例如，可能决定与位于特定城市的大型机程序进行接口。 - **企业架构原则**：可能包含只有使用或创建特定位置才能遵循的原则。例如，业务连续性原则可能要求在系统中断或灾难事件时仍能维持运营，这意味着需要一个单独的灾难恢复位置。 - **现有 IT 环境**：可能包含可以纳入架构的元素，这些元素可能暗示特定的位置。 - **非功能需求**：可能识别出对解决方案的某些方面要求特定位置的约束。例如，“呼叫中心必须位于我们的中央办公室”。此外，系统必须具备的某些质量，如可用性，可能暗示需要主灾难恢复位置和次灾难恢复位置。 - **系统上下文**：识别任何参与者（无论是人员还是外部系统）的位置。 以 YourTour 系统为例，通过考虑各种输入确定的初始位置如下： - 远程办公室：客户和旅游组织者可以通过支持互联网的设备访问 YourTour 应用程序。 - 分支机构办公室：客户和旅游组织者可以与销售职员会面以预订旅游。 - 中央办公室：整合所有远程办公室和分支机构办公室的信息。 - MyPay 数据中心：托管 MyPay 支付系统。 - MyReservation 数据中心：托管 MyReservation 预订系统。 虽然 MyPay 数据中心和 MyReservation 数据中心不在直接控制范围内，但可能需要在这些位置部署 YourTour 解决方案的元素，以促进与相关系统的集成。 #### 4. 识别节点步骤 在识别位置之后，接下来是识别将驻留在每个位置并最终部署组件的节点。在这个阶段，节点是纯粹的逻辑容器，没有识别出特定技术或产品的属性（除非有特定的约束）。 节点的识别基于对功能需求、非功能需求、功能模型、现有 IT 环境和架构决策等工作产品的分析： - **功能需求**：帮助了解系统参与者是谁以及每个参与者所需的功能，从而确定支持系统执行所需的计算资源。 - **非功能需求**：可能暗示系统需要具备特定的服务质量或不同级别的服务质量，这意味着需要引入不同的节点。 - **现有 IT 环境**：识别已经存在的节点，这些节点可以用于支持待开发系统组件的执行。 - **功能模型**：识别部署环境需要支持的组件，这可能暗示需要特定的计算资源。 - **架构决策**：可能建议使用某些节点。例如，在 YourTour 系统的中央办公室位置，假设目前所有与旅游相关的组件（包括旅游过程控制和旅游服务）将添加到一个逻辑服务器：旅游预订服务器。此外，内容管理服务器将托管内容管理应用程序，安全服务器包含特定的安全相关软件，集成服务器用于容纳任何特定的集成软件。 #### 5. 架构验证任务概述 架构验证任务的目的是验证架构工作产品的一致性，并确保跨架构工作产品的任何问题都得到一致解决。 - **角色**：应用架构师（次要）、数据架构师（次要）