在敏捷开发过程中我们还需要对系统架构进行设计吗？事实上Martin Fowler在Is Design Dead?文中已经给出了答案那就是我们同样不能忽略对系统架构设计和计划性设计(Planned Design)区别我们需要演进式设计(Evolutionary Design)在敏捷开发生命周期中我们通过每次迭代来丰富和更新我们设计方案以使其最大限度地符合客户对系统需求这里所指需求包括功能性需求和非功能性需求

　　在Agile Journal 4月刊中IBM's Methods Group敏捷专家Scott W. Ambler详细地阐述了在敏捷语境中架构设计思路方法他提出了所谓“架构预测(Architectural Envisioning)”思路方法以应对敏捷开发中逐步演进架构设计过程

　　Scott指出敏捷模型驱动开发(Agile Model Driven DevelopmentAMDD)明确地包括了需求分析和架构建模这个过程发生在敏捷项目开发第0次迭代中所谓第0次迭代就相当于项目热身活动是项目得以启动基础在此迭代期间团队(Team)需要充分地理解项目范围甄别可行地技术策略这个阶段所能够收集到信息将有助于你对整个项目最初粗略估计以制定合适项目计划从而获得启动项目资金和足够支持

　　敏捷模型驱动开发生命周期如下图所示:



　　根据图中所示在每次迭代初期制定迭代计划都应该包括建模工作在此期间可以召开建模头脑风暴会议讨论系统功能特征并研究实现这些特征高层设计策略大多数敏捷团队(Team)都会通过测试驱动开发(TDD)确定需求和设计细节

　　通过对架构预测可以在项目早期进行些高层次架构建模以助于团队(Team)和关键利益相关人商讨系统采取技术策略这行为关键目标是识别出架构策略而不是撰写如山般堆积文档从而使得你能够快速完成架构建模其中窍门就是尽量保持简单开发者不需要对大量细节进行建模而只需要足够即可如果你正在编写用例意味着你只需要以标注形式列出用例要点就足够好了如果你正在对领域建模可以直接在白板上绘图或者使用CRC卡片你目在于对信息共享和交流而不是编写细致文档

　　如果采用架构预测方式你需要对哪些内容进行建模呢？Scott在文中指出有如下 4部分内容需要建模:

　　1. 技术图表例如UML部署图这些图表有助于开发者预测主要软件Software和硬件组件包括你需要访问旧系统和数据库系统有可能会和它们进行交互

　　2. 用户交互流程图通过分析用户交互主要页面/外观和报告对系统UI进行架构设计如果在进行架构设计时候不考虑用户交互界面就可能存在潜在危机那就是你构建系统不是利益相关人所希望看到请记住UI才是最终用户使用系统

　　3. 领域图在最初架构建模中个重要组成部分是对领域高层建模模型可以非常微小只需要捕获主要业务实体以及它们的间关系有人可能认为领域模型应该属于需求建模部分而不是架构建模但正如上图所示这两者在第0次迭代中是并发进行

　　4. 变更情形就是在架构级需求中描述可能技术或业务变更而这些变更需要在未来能够提供支持变更情形要求你考虑架构扩展能力但并不是过度构建你系统你只是要考虑由于变更所造成影响以确保你构建系统还能够正常工作

　　架构建模是贯穿于整个项目周期因此这些图表就是在项目结束时形成整体文档基础由于你事先明确架构是演进因此就不必承担架构设计在项目早期必须“正确无误”压力而只需要在当前形势下保证足够好就可以了Scott建议使用白板和草稿纸等简便工具勾勒出这些模型版本当然如果团队(Team)成员具有熟练建模窍门技巧也可以使用专门建模工具这建议足以体现架构设计敏捷性和长篇累牍传统架构设计方式迥然区别

　　对于这样种架构设计方式熟悉传统架构设计方式架构师普遍不以为然Scott对这看法给和了强有力反驳他将架构设计场景分为 3种类型第种是架构师熟悉系统架构设计所必需技能和经验既然你已经熟悉了这些内容当然就没有必要作出完整设计了你只需要在白板上体现你架构设计保证团队(Team)每个人都能够按照相同体系架构进行实现就可以了

　　第 2种场景是架构师对相关窍门技巧和经验完全不知此时仍然只需要作少量建模即可你缺乏足够知识来完成细致而又全面架构设计反而会了解不够而导致从而增加项目风险并且阻碍了项目进度

　　第 3种场景则是架构师熟悉部分知识这种情形也是团队(Team)开发中最常见场景在这种情况下可以耗费几天时间作出个架构建模以验证系统可能存在风险并制定可能策略以减轻风险可能造成后果你可以实现些可工作代码来验证架构建模在这种情况下是非常有意义它使得你可以定义个致技术愿景为团队(Team)成员所分享并对系统主要问题进行研究

　　当你团队(Team)成员是分散在各地时或者当团队(Team)非常庞大下面分为多个小组时这种架构建模就能够带来无和伦比价值它有助于在团队(Team)成员的间建立个公共愿景更重要是它能够识别出分离组件/子系统以及这些组件接口旦识别出这些耦合度较低组件或子系统就能够合理地对团队(Team)进行分组并保证小组的间设计和实现致性



　　Scott指出所谓“架构预测”能够提供如下价值:

　　提高生产力

　　降低技术风险

　　减少开发时间

　　增强沟通

　　可伸缩敏捷软件Software开发

　　需要明确是这样种架构预测方式正好符合敏捷开发迭代需要在项目开发早期对系统整体进行次高层次概览并对关键业务需求进行甄别和分析划分合理系统模块有助于在迭代开发中为团队(Team)成员建立个统标准和目标而在每次迭代过程中团队(Team)就可以对本次迭代期间功能进行深入架构建模然后通过TDD充分理解需求对模块细节进行设计和实现这是敏捷架构设计核心操作原理它和敏捷开发原则是脉相承