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