Question

“敏捷”和“架构”常被看作是互斥的，然而现实却往往相反。有些软件团队认为架构是不必要的恶魔，另一些则认为他们需要重新考虑架构。

概括来说，架构就是结构和愿景，这个过程的关键在于理解重要设计决策。即使是最敏捷的软件项目都会有一些架构的顾虑，真的应该预先考虑，除非你经营的是最精益的初创公司，否则也确实找不到方向。因此，敏捷软件项目需要“架构”，但这似乎与过去十多年所宣传的敏捷相悖。一句话，敏捷项目需要架构，因此敏捷和架构并不冲突。那么，冲突在哪里？

冲突1：团队结构

架构和敏捷软件开发方法之间的第一个冲突与团队结构有关。传统的软件架构方法会有一个专门的软件架构师，他们就好像来自远离软件构建流程的象牙塔中的独裁者。解决方案架构师只提供大量设计文档给开发团队，放手不管，造成严重破坏。这种不幸的刻板印象导致在软件开发团队中安排一个专门的架构师的做法遭到反对。

敏捷软件开发团队努力争取的目标之一，是减少用文档传递来沟通产生的管理开支。对有些组织来说，这是加强合作、减少浪费的正确做法。这些组织往往更愿意组建由通才组成的、几乎可以胜任各种任务的小团队。事实上，由于敏捷方法的宣传方式，一种常见的看法是，敏捷团队必须由跨职能的团队成员组成，并且是自组织的。结果呢？很多敏捷团队会告诉你，他们“不需要讨厌的架构师”！

冲突2：流程和产出

第二个冲突，是敏捷和大型预先设计在流程和期望产出（即人们常说的架构）上的差异。敏捷方法的主要目标之一是周期性少量地提供客户价值，这关乎快速行动、接收反馈、拥抱变化。而大型预先设计的目标是在蓝图（通常是一个计划）到位前，对全部事情达成共识。

敏捷宣言1更推崇“随机应变”而非“依计划行事”，但这显然不意味着不做任何计划，似乎有些敏捷团队害怕做任何一点“分析”。结果为了避免大型预先设计，敏捷团队常常不做任何预先设计，而是用“浮现式设计”或“演化架构”之类的术语来为他们的做法辩解。我还听说有团队宣称他们采用的测试驱动开发（TDD，Test Driven Development）根本不需要“架构”，但也就是这些团队在将来某个时候会为不断重构所累。

1http://agilemanifesto.org

软件架构提供了TDD、BDD、DDD、RDD和代码整洁的分界线

每当我和团队谈起软件架构，都有一个被反复问到的问题，TDD2、BDD3、DDD4、RDD5等技术跟架构的关系如何？这个问题其实是问xDD是否是“软件架构”的替代，特别是在“敏捷环境”中。简短的回答是否定的。稍长的回答是，思考软件架构的过程其实是确定范围，在范围之内你可以用任何一种xDD和你喜欢的敏捷实践来构建软件。

2测试驱动开发，http://en.wikipedia.org/wiki/Test-driven_development。

3行为驱动开发，http://en.wikipedia.org/wiki/Behavior-driven_development。

4领域驱动设计，http://en.wikipedia.org/wiki/Domain-driven_design。

5责任驱动设计，http://en.wikipedia.org/wiki/Responsibility-driven_design。

对我来说，原因很简单：你需要思考架构的驱动力（影响最终软件架构的重要事情），包括下面这些。

功能需求：需求驱动架构。不管怎么捕捉和记录需求（比如，用户故事、用例、需求规格书、验收测试等），你都要大概知道你在构建什么。

质量属性：非功能需求（比如，性能、可扩展性、安全等）通常是技术方面的，也很难改造。理论上，这些都需要体现在初始的设计中，忽视这些属性会导致软件系统要么做得不够，要么做得太过。

约束：约束普遍存在于现实世界，包括批准的技术清单、规定的集成标准、目标部署环境、团队规模等。再说一次，不考虑这些会导致你交付的软件系统与环境不匹配，增加不必要的摩擦。

原则：是在试图为软件提供一致性和清晰度时你想要采用的东西。从设计的角度来看，这包括你的分解策略（比如，层、组件和微服务的对比）、关注点分离、架构模式等。明确概述一套初始的原则至关重要，这样构建软件的团队才会朝着同一方向出发。

从象牙塔和大型预先设计中分离出架构

多数情况下，这些冲突会造就缺乏合适的技术领导力的混乱团队。结果如何？做出来的软件系统看起来一团乱，也不符合非功能需求等关键的架构驱动力。

架构是改变起来很困难或者成本很高的东西，跟那些你不能用一个下午就轻松完成重构的、大的或者“主要”的决策有关。它包括核心技术选择，全面的高层次结构（全局）以及对如何解决各种复杂、高风险、关键问题的理解，等等。软件架构很重要。

大型预先设计通常涵盖了这些对架构的顾虑，但往往想得太多。有一个技巧来区分哪些是重要的：定义一个高层次结构，设定愿景，这很重要；在开始编码之前，绘制无数个类的详图，则多半不重要。搞清楚如何解决怪异的性能需求很重要，搞清楚每个数据库字段的长度就不太重要。

敏捷和架构并不冲突。与其盲目听从别人的指点，软件团队更应剔除炒作，理解技术领导力的方式，在其独特的环境下量化所需的预先设计。

考虑架构的驱动力不需要花很长时间，却能为软件设计的其他部分提供一个开始。当然，这并不意味着架构不应该更改，特别是当你开始编写代码、获得反馈后。关键在于你现在有了一个框架和一定的工作范围，能为团队提供一些经常需要的愿景和指导。我的经验是小方向有大用场。