创建解决方案体系结构
创建卓越的体系结构包括研究备选体系结构策略。 根据选择的平台、所采用的技术和代码重用，备选策略具有不同的优势。 设计各种策略并生成概念证明，以便进一步研究各种策略的成本和优势。 针对产品和质量要求评估多种策略，并最终选择一种策略以用于实现产品。 最后，安全和性能是体系结构的重点所在，与此相关的工作必须在整个产品中开展实施。
主题内容
创建备选体系结构分区设计
设计系统体系结构部署
创建概念证明
评估备选方案
选择体系结构
开发性能模型
创建备选体系结构分区设计
分析问题所在，并考虑不同方法。 选择一组代表关键业务和技术挑战的要求。 检查这些挑战的特征（如集成旧系统），并根据当前需求、代码可重用性和维护成本预测未来需求。
创建应用程序关系图
使用域模型和要求作为信息，创建一个代表系统的核心逻辑元素的应用程序关系图。 该关系图稍后将分为多个系统关系图。 将考虑和评估备选分区方案。
表示应用程序关系图的方法之一是以统一建模语言 (UML) 用例关系图表示。 此类关系图可以显示主要子系统及其依赖关系。 此外，可以将用例放置到各子系统中，以便显示管理各用户方案的子系统。
建立评估条件
确定明确要求和方案所采用的条件，这些要求和方案代表着重大体系结构挑战。 查阅企业现有的体系结构文档以确定条件。 查看必须应用于新应用程序的任何业务要求、技术要求和企业标准。 捕获公认的在体系结构方面有着重要意义的其他条件，例如，与旧系统集成、代码可重用性、重用现有供应商的库和平台，以及控制维护成本。 捕获代表实现技术解决方案时的风险和成本的其他条件。
选择候选要求组
根据评估条件评估每个服务质量要求和产品要求。 如果要求代表体系结构挑战，请将其视为用于建模的候选要求。 例如，新产品必须支持较早客户数据库的要求满足与旧系统集成的条件。 此类要求是用于对集成运作方式进行建模的候选要求。
选择候选方案组
根据评估条件评估各方案。 如果方案代表体系结构挑战，请将其视为用于建模的候选要求。 例如，用户下载客户端更新的方案满足与维护成本相关的条件。 此类方案是用于对客户端更新的最佳处理方式进行建模的候选要求。
减少候选组
查看候选方案和要求。 移除与评估条件重复或由其他方案和要求更好地表示的方案和要求。 将候选组调整为一个代表主要体系结构挑战、风险和新应用程序成本的核心组。 保留在构造技术解决方案时最好地表示评估条件、展现最大风险和最大潜在成本的方案和要求。 保留代表应用程序最全面或最关键部分的方案和要求。
创建分区条件
使用要求作为动机，对已建立的体系结构模式（如外观或模型-视图-控制器）进行分析，确定用于实现的潜在候选要求。 通过模式动机确定候选模式，并从耦合、内聚力、扩展性、适应性和灵活性方面考虑所做的设计折衷。 选择一组候选实现方案作为评估备选方案。
设计系统体系结构和部署
系统体系结构定义对应用程序关系图中确定的元素的分组和配置。 创建系统关系图以捕获系统体系结构，以便寻求每种可能的体系结构方法。 部署关系图显示基于依赖关系和核心功能的部署步骤。 基础结构架构师创建逻辑数据中心关系图，该关系图描述将部署应用程序的数据中心的逻辑结构。 部署关系图根据逻辑数据中心关系图进行验证，以便确保可以部署系统。
创建系统模型
架构师和开发人员主管根据应用程序关系图创建系统关系图。 通过系统关系图，您可以通过用应用程序关系图上的元素来组成部署单位，以便将可重用的应用程序系统设计为部署单位。 此外，还可以设计包含其他系统的更大、更复杂的系统，以将其用于分布式系统方案，并提取这些系统中的应用程序的详细信息。 将每个新的关系图文件签入到版本控制中。
可以通过以下方式在 Visual Studio 中表示系统关系图：
用例图。 主要用户方案作为用例表示，主要系统组件作为子系统显示。 可将每个用例放置到处理该用例的子系统中。 有关详细信息，请参阅UML 用例图：准则。
UML 组件图。 这些关系图使您可以显示各个组件之间的信道和依赖关系。 您可能还需要创建类图来描述组件接口上的可见类型，您可以创建序列图以显示组件之间的交互。 有关更多信息，请参见UML 组件图：准则、UML 类图：准则和UML 序列图：准则。
层关系图。 层关系图描述应用程序的块结构。 它仅显示组件及组件之间的依赖关系。 其优点在于：在编写代码之后，您可以根据此关系图验证代码和依赖关系。 有关详细信息，请参阅层关系图：指南。
对于每个子系统，您可以创建一个用于更详细地描述其类型和行为的包。 有关详细信息，请参阅定义包和命名空间。
创建概念证明
创建体系结构概念证明可以缓解重大项目风险。 请务必在项目中尽早解决风险，以便可以在仍可以轻松修改体系结构的基本部分时制定关键策略和体系结构决策。 创建早期概念证明可以减少项目整体风险和未知因素。 降低项目风险和减少未知因素可以使后续迭代中的计划和估计更加准确。 概念证明可以临时使用，并在问题解决之后丢弃，也可以作为核心体系结构的基础生成。
检查风险
了解可确定风险或体系结构决策的元素。 检查相关方案和服务质量要求。 检查任何目标环境隐患。
计划方法
确定所需概念证明的形式。 使用应用程序关系图和系统关系图来帮助计划。 仅解决根据风险确定的体系结构问题。 查找最简单的解决方法。
生成并运行概念证明
生成概念证明。 可以根据应用程序关系图实现概念证明。 集中关注要解决的问题。 将概念证明部署到与逻辑数据中心关系图相符的物理环境。 该物理环境应尽可能密切地符合逻辑数据中心关系图设置。 针对高风险问题对概念证明进行测试。
评估备选方案
使用轻量体系结构备选分析方法 (LAAAM) 帮助在用于生成应用程序的不同体系结构策略之间作出选择。 LAAAM 通常需要一天时间即可完成。 从生成实用工具树入手，该树描述基于要求的应用程序质量和功能的关键推动因素。 将每个推动因素编写为一个方案，该方案采用声明形式，并编写为背景、促进因素和响应。 使用评估列表评估每个策略对每个方案的处理情况。
创建实用工具树
查看服务质量要求和产品要求，以确定应用程序质量和功能的关键推动因素。 构造表示应用程序整体质量的实用工具树。 树中的根节点标记为“实用工具”。 后续节点通常采用标准质量术语进行标记，例如，可修改性、可用性和安全性。 该树应表示质量的分层性质，并提供优先级设置基础。 该树中的每一级别都会对质量进行进一步优化。 最后，这些质量即成为方案。
构造评估列表
为实用工具树中的每个叶编写一个方案。 该方案采用背景、促进因素和响应的形式（例如，“在正常操作下，应在不到 100 毫秒的时间内执行数据库事务”）。
创建一个电子表格或表，并将每个方案作为一行输入在上述评估列表中。 将每个体系结构策略输入为一列。 在策略和方案的每个相交处，从 1 到 4 分等级输入一个评级。
评级应考虑以下因素：
开发成本 此解决方案的实现是简单还是困难？ 它会对其他领域产生哪些影响？
运营成本 在运行时，此解决方案是否便于运行，或者是否会对可用性、性能等产生负面影响？
风险 此解决方案是否肯定能够成功解决问题，或者是否存在未知成本？ 此解决方案是否会对团队在以后容纳要求改进的能力产生负面影响？
如果已为策略生成了概念证明，请使用此概念证明中的信息帮助确定各个值。
在表的底部，将方案的各个值相加。 使用这些数字向讨论提供信息，以确定备选体系结构。
将完成后的评估列表上载到项目门户网站。
选择体系结构
评审会议在创建评估列表之后举行，以确定在下一次迭代中使用的体系结构。 评估列表和创建概念证明时所发现的信息可用于帮助制定决策。 在选择体系结构之后，会将体系结构关系图作为参考解决方案签入，并会创建论证文档以捕获选择背后的原因。
准备评审
架构师和开发人员主管确定评审建议的体系结构的评审人员，并向各参与者发放体系结构文档。
评审系统体系结构和部署体系结构
评审会议期间，相关人员将对系统关系图、部署报表和逻辑数据中心关系图进行评审。 目标是选择要在下一次迭代中实现的体系结构。
考虑每个体系结构的评估列表评级，以帮助评估每个体系结构的适用性。 考虑任何从概念证明中发现的信息，例如，与实现不同体系结构相关的成本或复杂性。 如果逻辑数据中心关系图表示无法修改的现有数据中心，请不要对此进行评审。 如果要创建数据中心，请评审关系图以获取部署注意事项。 选择要使用的体系结构。 根据方案评审体系结构概念，以便验证解决方案是否满足客户需求且是否完整。
创建参考解决方案
创建可捕获会议决策的论证文档。 将该文档上载到项目门户网站。 对于所选体系结构，请将其作为参考解决方案签入任何应用程序关系图、系统关系图或逻辑数据中心关系图，以用于实现下一次迭代中的功能。 向整个团队及任何相关团队公布有关为下一次迭代选择的体系结构的决策。
开发性能模型
性能模型用于确定和解决应用程序中的潜在性能问题。 性能模型根据服务质量要求开发而来，随后会将该模型分为多个开发任务。 每个开发任务都指派有实现的性能预算。
确定链接到性能服务质量要求的方案。 将开发任务映射到这些方案。 在服务质量要求列表中，确定应用程序的工作量。 通过使用工作量估计和服务质量要求列表，确定每个关键方案的性能目标。 这些目标包括响应时间、吞吐量和资源使用率。 确定为实现性能目标而已编入预算的性能相关资源。 性能相关资源的某些示例包括执行时间和网络带宽。 确定每种资源允许分配的最大数量。
将资源预算分布到每个方案的各个处理步骤。 如果不确定预算的分配方式，请尽量猜测，或者在各个步骤之间平均划分资源。 预算将在验证过程中得以改进。 在相应开发任务上附加或编写所进行的分配。
查找会为性能目标的实现带来风险的预算分配方式。 应考虑各种有助于实现性能目标的平衡因素，例如，设计和部署备选项。 如有必要，请重新评估服务质量要求。
确定不符合预算分配方式的方案。 评估方案性能。 如果未提供代码，请在早期迭代中采用原型构造方法。 通过使用在验证时获取的数据，根据需要重复预算、评估和验证步骤。
开发威胁模型
有关详细信息，请参见 Microsoft 网站上的以下页面：安全开发人员中心。