在敏捷开发中采用演进式架构设计
在敏捷开发过程中，我们还需要对系统架构进行设计吗？事实上，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充分理解需求，对模块的细节进行设计与实现。这是敏捷架构设计的核心操作原理，它与敏捷开发原则是一脉相承的。
在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充分理解需求，对模块的细节进行设计与实现。这是敏捷架构设计的核心操作原理，它与敏捷开发原则是一脉相承的。
