架构设计的重要性是无需赘言的。架构的生命力往往伴随业务的成长而成长，甚至超越具体技术的变化，因而如何设计能够不断演进，始终支持业务发展的架构一直是软件开发方法研究的核心。
传统设计方法的困境
在传统开发方法中，架构设计是围绕着设计文档展开的。具体实施过程有如下特点：
- 预先设计。在实际开发工作开始前，少数架构师们需要用相当长的一段时间来进行架构设计和详细设计，力求得到一个具有高度可扩展性的良好架构。产出为“概要设计文档”和“详细设计文档”。根据项目规模，这个过程一般持续数周不等
- 短暂评估。架构师产出的设计文档要经过架构设计评审委员会或类似组织的评审，这个过程一般持续数天
- 依据设计进行实现。经过评审的设计会交到开发者手中，进行实际的编程实现，这个过程往往以数月，甚至数年来计算。
思考传统架构设计方法，我们不禁要提出这样的问题：
为什么传统开发方法会如此重视前期预先架构设计，以至于希望在实际开发前把架构设计做到尽善尽美？
答案在于：在传统的概念中，一旦设计成型，架构是很难调整的，例如，传统的软件工程教科书中都会讨论“架构调整的成本”问题：如果在设计中实现一次修改的成本为1；在实现过程中相同修改的成本就是5～10；在测试、部署阶段，同样的修改成本将上升到50～100；维护阶段同样修改的成本更是成指数曲线上升。
但这种策略存在一个根本问题：软件的“扩展”究竟会如何发生是很难预计的。面对这一困境，传统开发方法的解决方案是继续增加预先设计的时间和人力，但往往收效甚微。
传统设计困境分析
传统预先设计方法恶性循环的原因有三点，对应上述实施过程的特点：
- 设计和实现脱节。无论是少数架构师，还是评审，一般都不参与实际的软件开发。基于经验的设计一方面无法得到实现的验证；另一方面，当需求发生变更时，无法随之演进。
- 评估的可靠性有限。对预先设计评估的只能基于已知的需求，而系统的可扩展性是在应对变更的需求时体现出来的，因此评估具有很大的局限性。
- 实现者缺少对预先设计进行修改的支持。当预先设计不能满足实际需求时，开发者或者修改设计，或者置需求变更不理，继续沿预先设计开发。忽视需求变更的结果只能是系统无法满足应用（而开发者也可以将责任推到架构师身上）；如果开发者根据需求修改设计，则预先设计不但事实上已经成为浪费，而且已有的设计和实现往往更成会增加修改的难度，原因在于，如果预先设计的扩展性没有用到，则这些额外的扩展性带来的对当前需求无用的复杂性，这些复杂性增加了理解、修改系统的难度。
敏捷架构解决方案
敏捷方法认为，好的架构就是适应于当前需求的架构。也就是说，如果当前的应用和需求发生了变化，特别是发生了很大的变化，原来的好架构就完全可能不合适新的变化，也就变成了不好的架构。
传统开发方法中，经常需要在项目的二期、三期抛弃已有成果，重新开始，一个重要原因就是原来的架构体系已经到了不能支撑现有应用的程度了。尽管传统开发方法尝试对此加以补救，增加了很多相应的流程（例如增改需求之后就会伴随着架构设计修改和评审），但架构不能适应新需求的情况仍然不时发生，因为需求的变化本就是无法预测的。
在总结以往方法学的经验和教训的基础上，敏捷方法提出了一系列的架构设计方法：
- 以测试驱动开发为保证的演进式设计策略
- 以简单设计为目标设计原则
- 通过持续集成最大程度的减少子系统间的架构冲突
- 通过结对编程进行持续设计评审，减少实现偏离设计的几率
从上述的方法中可以看出在设计方面敏捷方法与传统方法的一个本质区别：
在实现过程中进行设计，实现和设计密不可分
下面我们将在介绍这些敏捷实践的过程中介绍敏捷的设计/实现实践。
