建立弹性软件架构

对于基础架构，我还有几个观点要说明。在单一团队工作结束的时候，将建立系统早期
的、关键性的第一个版本，这是一个可执行的版本，我们称之为架构基线版本。在建立好架
构基线之前可能要花费几个迭代周期，但完成以后，将会证实你的假设、以及系统开发方法，
也就可以降低风险，基于这个架构，其它部分的开发速度将会大大加快。
一个好的架构要确保不同类型的关注点互相独立，当其中一个发生改变的时候，不至于
影响系统的其它部分。架构师应该致力于创建一个弹性架构，也就是说各个不同类型的关注
点保持独立，而系统中的一部分发生变化的时候，对其余部分的影响要最小。架构设计也必
须满足性能、可靠性等系统的关注点。
好的架构必须使每个关注点互相分离，尽可能使系统一部分的改变不至于影响到其它部
分，即使有一定影响，也要清晰的识别出哪些部分需要改变，如果需要扩展架构，影响应该
最小化，已经可以工作的部分应该可以继续下去。
1，分离功能性需求
一般的希望保持功能性需求之间是分离的，功能表明了不同最终用户的关注点，并且可
能互相独立的发展，所以不希望一个功能的改变会影响到到其它。功能性需求一般是站在问
题域的高度来表达的，因此很自然的希望系统特定功能从领域中分离出来，这样，就便于把
系统适配到类似的领域中。另一方面，一些功能需求会以其它功能需求扩展的形式来定义，
这样更需要它们互相独立。
2，从功能需求中分离出非功能性需求
非功能性需求通常标识所期望的系统质量属性：安全、性能、可靠性等等，这就需要通
过一些基础结构机制来完成，比如，需要一些授权、验证以及加密机制来实现安全性；需要
缓存、负载均衡机制来满足性能要求。通常，这些基础结构机制需要在许多类中添加一小部
分行为（方法），这就意味着与基础结构机制实现的一点变动都会造成巨大的影响，因此，
要使功能需求与非功能需求之间保持分离。
3，分离平台特性
现在的系统运行在多种技术之上，比如身份验证的基础结构机制就可能有许多可选的技
术，这些技术经常是与厂商有关的，当一个厂商把它的技术升级到一个新的、更好的版本的
时候，如果你的系统适紧密依赖于这项技术前一个版本的，那么进行升级就并不那么容易，
所以要使平台特性与系统保持独立。
4，把测试从被测单元中分离出来
作为完成一项测试的一部分工作，你必须采用一些控制措施和方法（调试、跟踪、日志
等），这些控制措施是保证系统运行流程符合测试要求的规程。这些方法是为了在系统执行
的过程中提取信息，以确认系统确实是按照预期的测试流程执行的。
这些控制措施和方法，经常需要在测试过程中向系统内插入一些与系统一起运行的代
码，在擦拭完成以后这些代码将会被删去，因此，希望把测试的实现与被测的系统分离开来。