本篇详细介绍架构的步骤
1、确定架构的目标
架构的目标就是你的结构和设计过程的目的和限制，练习的范围，帮助你决定什么时候算是完成了。在你确定架构的目标的时候，可以参考下面的几个关键点：
首先确定架构的目的。你花在架构和设计的每一个阶段的总时间，将会依赖于这些目的。例如：你是否建立原型？是否测试潜在的路径？是否为一个新的应用已经开始长期的架构过程？
确定谁将会消费你的架构。确定你的架构是否会被其他架构使用，对于开发者、测试者、操作员、管理者是否可以获得？考虑你的听众的需要和经验，似的你的架构更容易被他们理解。
确定你的限制。了解你的技术选型和限制，使用限制，部署限制。在开始就明确你的限制，以便在后面开发的过程中不会浪费时间，和碰到令人奇怪的问题。
范围和时间
以架构的高层目标为基础，你可以确定花费在每一次架构行为上面的时间。例如：原型可能只需要几天来设计，一个完整的、详细的复杂系统的架构可能需要几个月来设计（需要迭代好多次的架构和设计）。使用你理解的架构目标确定花费在每一个步骤的时间和精力，计算可能的将来的产出结果。清晰的定义架构的目的和优先级。目的可能包含下面的内容：
- 建立一个完整的应用设计。
- 建立原型。
- 确定关键的技术风险。
- 测试潜在的可能性。
- 建立共享的模型，方便理解系统。
在设计上，每一次都会有不同的重点，完成的时间也会有变化。例如：如果你想要确定你的认证架构的风险的话，你将会在认证的方案，认证架构的限制条件，可能选择的认证技术上花费大量的时间和精力。但是，如果你处在为一个应用考虑完整架构的开始阶段的话，验证架构只是众多重点中的一部分。
一些架构行为的例子是建立在原型基础上的，通过原型来获取反馈。通过原型验证架构的合理性，通过原型细化架构。
2、关键的场景
在设计和架构的上下文环境，用例用来描述系统和一个或者多个执行者（一个用户，也可能是一个系统）之间的交互行为。一个场景集中描述用户和系统的交互行为，目的是确定多个关键的场景，来帮助你的在架构的时候做决定。目的是在用户，业务，系统目标之间达到平衡。
重要的架构用例
结构化的重要用例在设计中会对很多方面产生影响。这些用例对于成功的应用尤其重要。他们对于已经部署的应用也很重要，他们必须被足够的试验，来帮助评估架构。包括下面的用例：
- 关键的业务。和其他功能相比，这些用例对于用户有很高的使用级别，是特别重要的，有很高的风险。
- 高影响的。例如：Create,Read,Update,Delete(CRUD)操作的安全性。
3、应用概述
对于应用达到什么要求，什么时候完成，应该有一个概述。这个概述使得你的架构更加明确，连接真实世界的限制和精确性。一个应用概述应该包括下面的部分：
- 确定应用的类型。首先，确定你的应用是什么类型的，是一个移动应用、富客户端应用、富Internet应用、服务、web应用，还是这些应用的综合。
- 确定部署的限制条件。当你设计应用的时候，一定要把相关的政策、法规，基础设置考虑进去。如果现有环境是不灵活的、固定的，你的设计一定要考虑环境的限制。你的应用还要加入QOS，例如：安全和可靠性。有些时候要需要考虑协议限制和网络限制。
- 确定重要的架构风格。确定在设计中使用的架构风格。
- 考虑相关的技术。
相关技术：
- Mobile Application移动应用，面向手持设备的应用。
- Rich Client Application富客户端应用，例如：WPF等，客户端具有丰富表现能力的应用。
- Rich Internet Client Application富internet应用，在原有浏览器的基础上， 增加客户端的交互性，例如：Silverlight，ajax等等。
- Web Application，典型的web应用。
- Service Application服务应用，以提供服务为目的的应用。webservice，Wcf等。
白板化你的架构
使用白板描述你的架构是很重要的。通过白板，或者其他形式共享你的架构，方便开始讨论。如果可以提供一个清晰的图例的话，别人会更容易理解你的架构，你也更容易讲清楚里面的细节。
4、关键的问题
潜在的问题包括：新技术，关键的业务需求。例如：第三方的服务客户替换吗？可以支持一种新的客户端类型吗？可以适应业务规则的变化吗？引入新的技术可以吗？
质量指标
- 系统质量。整体来看，系统的质量，例如可测试性。
- 运行质量。系统运行的时候直接表现出来的质量问题，例如：性能、可管理性、可靠性、扩展性、安全性。
- 设计质量。例如：灵活性、可维护性、重用性。
- 用户质量。系统的可用性。
跨越多个层次的关注点：
- 认证和授权。
- 缓存。
- 通信
- 配置管理
- 异常管理
- 日志和性能指标显示
- 验证
5、候选解决方案
在定义了关键问题之后，你可以建立一个架构的基线版本，然后开始细化建立一个满足需求的架构候选方案。随着架构的深入，你会遇到新的需求和发现新的问题，然后再次验证你的候选方案，通过不断的迭代来改进架构设计。
在测试一个新的候选方案的时候，可以从下面的问题来考虑：
- 当前架构是否没有引入新的风险？
- 和前一个架构相比，是否缓解了已知的风险？
- 架构满足额外的需求了吗？
- 架构是否满足了重要的用例？
- 架构是否满足质量指标?
- 架构是否满足了额外的跨层关注点？