在敏捷开发过程中，我们还需要对系统架构进行设计吗？事实上，Martin Fowler在《Is Design
Dead?》一文中已经给出了答案，那就是我们同样不能忽略对系统架构的设计。与计划性的设计（Planned
Design）不同，我们需要演进式的设计（Evolutionary
Design）。在敏捷开发的生命周期中，我们通过每一次迭代来丰富与更新我们的设计方案，以使其最大限度地符合客户对系统的需求。这里所指的需求，包括
功能性需求和非功能性需求。
在Agile Journal四月刊中，IBM's Methods
Group的敏捷专家Scott W. Ambler详细地阐述了在敏捷语境中的架构设计方法，他提出了所谓“架构预测（Architectural
Envisioning）”的方法，以应对敏捷开发中逐步演进的架构设计过程。
Scott指出，敏捷模型驱动开发（Agile Model Driven
Development，AMDD）明确地包括了初始需求分析与架构建模，这个过程发生在敏捷项目开发的第0次迭代中。所谓第0次迭代，就相当于项目的热
身活动，是项目得以启动的基础。在此迭代期间，团队需要充分地理解项目的范围，甄别可行地技术策略。这个阶段所能够收集到的信息将有助于你对整个项目最初
的粗略估计，以制定合适的项目计划，从而获得启动项目的资金与足够的支持。
敏捷模型驱动开发的生命周期如下图所示：
根据图中所示，在每次迭代的初期，制定的迭代计划都应该包括建模的工作。在此期间，可以召开建模的头脑风暴会议，讨论系统的功能特征，并思考实现这些特征的高层设计策略。大多数敏捷团队都会通过测试驱动开发（TDD）确定需求与设计的细节。
通过对架构的预测，可以在项目早期进行一些高层次的架构建模，以助于团队与关键利益相关人商讨系统采取的技术策略。这一行为的关键目标是识别出架构策略，
而不是撰写如山一般堆积的文档，从而使得你能够快速完成架构建模。其中的窍门就是
尽量保持简单。
开发者不需要对大量的细节进行建模，而只需要足够即可。如
果你正在编写用例，意味着你只需要以标注形式列出用例的要点就足够好了。如果你正在对领域建模，可以直接在白板上绘图，或者使用CRC卡片。你的目的在于
对信息的共享与交流，而不是编写细致的文档。
如果采用架构预测的方式，你需要对哪些内容进行建模呢？Scott在文中指出有如下四部分内容需要建模：
1.
技术图表。例如UML部署图。这些图表有助于开发者预测主要的软件和硬件组件，包括你需要访问的旧系统和数据库，系统有可能会与它们进行交互。
2.
用户交互流程图。通过分析用户交互的主要页面/外观和报告，对系统的UI进行架构设计。如果在进行架构设计的时候不考虑用户交互界面，就可能存在潜在危机，那就是你构建的系统不是利益相关人所希望看到的。请记住，UI才是最终用户使用的系统。
3.
领域图。在最初的架构建模中，一个重要的组成部分是对领域的高层建模。模型可以非常微小，只需要捕获主要的业务实体，以及它们之间的关系。有的人可能认为领域模型应该属于需求建模的一部分，而不是架构建模。但正如上图所示，这两者在第0次迭代中是并发进行的。
4.
变更情形。就是在架构级需求中描述可能的技术或业务变更，而这些变更需要在未来能够提供支持。变更情形要求你考虑架构的扩展能力，但并不是过度构建你的系统。因为你只是要考虑由于变更所造成的影响，以确保你构建的系统还能够正常工作。
架构建模是贯穿于整个项目周期的，因此这些图表就是在项目结束时形成的整体文档的基础。由于你事先明确架构是演进的，因此就不必承担架构设计在项目早期必
须“正确无误”的压力，而只需要在当前形势下保证足够好就可以了。Scott建议使用白板和草稿纸等简便工具，勾勒出这些模型的初始版本。当然，如果团队
成员具有熟练的建模技巧，也可以使用专门的建模工具。这一建议足以体现架构设计的敏捷性，与长篇累牍的传统架构设计方式迥然不同。
对于这样一种架构设计方式，熟悉传统架构设计方式的架构师普遍不以为然。Scott对这一看法给与了强有力的反驳。他将架构设计场景分为三种类型。第一种
是架构师熟悉系统架构设计所必需的技能与经验。既然你已经熟悉了这些内容，当然就没有必要作出完整的设计了。你只需要在白板上体现你的架构设计，保证团队
的每个人都能够按照相同的体系架构进行实现就可以了。
第二种场景是架构师对相关技巧与经验完全不知。此时，仍然只需要作少量的初始建模即可。因为你缺乏足够的知识来完成细致而又全面的架构设计，反而会因为了解不够而导致错误，从而增加项目的风险，并且阻碍了项目的进度。
第三种场景则是架构师熟悉部分知识。这种情形也是团队开发中最常见的场景。在这种情况下，可以耗费几天时间作出一个初始的架构建模，以验证系统可能存在的
风险，并制定可能策略以减轻风险可能造成的后果。你可以实现一些可工作的代码来验证架构。建模在这种情况下是非常有意义的，因为它使得你可以定义一个一致
的技术愿景，为团队成员所分享，并对系统的主要问题进行思考。
当你的团队成员是分散在各地时，或者当团队非常庞大，下面分为多个小组时，这种初始的架构建模就能够带来无与伦比的价值。它有助于在团队成员之间建立一个
公共的愿景，更重要的是它能够识别出分离的组件/子系统，以及这些组件的初始接口。一旦识别出这些耦合度较低的组件或子系统，就能够合理地对团队进行分
组，并保证小组之间设计与实现的一致性。
Scott指出，所谓的“架构预测”能够提供如下价值：
1. 提高生产力
2. 降低技术风险
3. 减少开发时间
4. 增强沟通
5. 可伸缩的敏捷软件开发。
需要明确的是，这样的一种架构预测方式，正好符合敏捷开发迭代的需要。在项目开发早期，对系统整体进行一次高层次的概览，并对关键业务需求进行甄别与分
析，划分合理的系统模块，有助于在迭代开发中为团队成员建立一个统一的标准与目标。而在每次迭代过程中，团队就可以对本次迭代期间的功能进行深入的架构建
模，然后通过TDD充分理解需求，对模块的细节进行设计与实现。这是敏捷架构设计的核心操作原理，它与敏捷开发原则是一脉相承的。