架构定义：捕捉到了非功能性需求后，下一步是开始思考你打算如何去解决干系人提出的这些问题

并定义它的架构。公平的说每个软件系统都有一个架构，但并不是每个软件系统都有一个定义好的架
构。这正是问题的关键。架构定义过程让你想清楚你打算怎么在兼顾需求和限制的情况下把问题解决
好。架构定义是将结构，方针，原则和领导力引入软件项目的技术层面。定义架构是作为软件架构师
的工作，但是从头开始设计一个软件系统和对已存在的系统扩展是相当不同的。

技术选型：技术选型通常是一个有趣的练习，但它也有公平的挑战,因为你需要综合考虑成本、许

可、供应商关系、技术策略、兼容性、协作性、支持、部署、升级的政策以及最终用户环境等各方
面。综合这些因素，通常会导致简单选择类似富客户端技术而进入了完全的噩梦。接下来的问题就是
这些技术是否能真正有用。技术选型是彻头彻尾的风险管理；复杂性或不确定性太高的时候要减轻风
险，当有机会或利益的时候要引入风险。技术决策需要考虑多种因素，而且所有的技术决策需要被检
查和评估。这包含软件项目的主要组成部分乃至开发中引入的类库和框架。如果定义一个架构，你还
需要有信心认为选择这项技术是正确的。同样在技术评估中也还是存在开发新系统和向现有的系统增
加新技术的不同点。

架构评估：

如果你设计软件，你需要问问自己你的架构是否有用。对我来说，一个架构是成功的，

如果它满足非功能性需求，而且为其他部分的代码提供必要的基础，并为解决和存在的业务问题提供
足够的平台。软件的一个最大的问题就是它复杂而抽象，导致很难从 UML 图或代码本身去设想出运行
时的特性。在软件开发周期中我们进行了很多不同类型的测试，这样我们能够有信心我们发布的系统

在推出时能够正常运行。我们为什么不对架构也这样做呢？如果能够测试你的架构，那你就可以证明
它是有效的。如果你能尽早做到这一点，你就能减少项目失败的风险，而不是简单地希望一切都好。