（四）对更快的探索：敏捷开发、DDD和微服务
对效率的探索涌现出了更多的软件工程方法、设计方法，不同方法间逐渐形成组合，从单一方法到“组合拳”也是一个很有意思的过程。不满足于软件工程的进步，90年代，敏捷开发的思路开始出现。2001年，在美国犹他州雪鸟滑雪胜地，敏捷方法发起者组织敏捷聚会并起草大名鼎鼎的《敏捷宣言》，“敏捷”开发也在这次聚会上正式定名。虽然目前对敏捷开发的认识还不是很一致，但大体上的开发流程，可以在网上找到很多类似图3的介绍：
敏捷开发的矛头可谓直指“瀑布模型”，大多数讲敏捷开发的书几乎都以此开头。笔者并非一个敏捷实践者，因此也无法深入讨论这一方法的优缺点，但是从对其实现过程的介绍来看，企业架构的设计显然没有包含在敏捷过程中，敏捷强调的是产品和用户维度，而且敏捷的“轻文档”理念与企业架构已有的“重文档”方法之间也是有矛盾的。
由于研究的人很多，敏捷开发在软件过程管理和软件设计方面都有较快发展。尽管有人质疑其效果，但是据称全球排名第11的资产管理公司——荷兰国际集团（ING）是在全公司推行敏捷开发的，该公司拥有员工113,000人，在全球50个国家为6千多万客户提供金融服务。
除了对过程的加速，架构设计方法本身也有创新。2003年，Eric Evans提出了DDD，也即领域驱动设计方法，该方法的特点是在需求分析、软件设计方面的一体化实现，通过领域模型直接形成可以指导到“类”设计的软件架构模型。但是DDD明显只是一个软件架构设计方法，而非企业架构设计，并且，DDD领域的大师级人物Vaughn Vernon认为企业级是无法从顶层直接设计的，只能在领域建模完成后，逐个领域地进行尝试性融合。Eric Evans也在其书的结尾对“总体规划”方法表示了一种委婉的不信任。DDD最经典的架构图如图4和图5所示：
Eric Evans曾提出该方法主要面向敏捷过程，二者其实在方法层面有相似之处，都强调快速由需求进入开发过程，也都注重对模式的运用。但是因为DDD方法掌握起来有一定难度，因此并没有真的随着敏捷开发“火”起来，倒是借了另一种架构风格的“东风”，微服务。
微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格注重用具备独立数据库的微服务来替代原有的单体应用设计方式，每个微服务运行在自己的进程中，并使用轻量级机制通信，通常是Restful API。这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，服务可以使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。从理念上看，极具灵活性、快速响应能力、可复用性和扩展性，案例上更是有传奇公司Netflix做标杆。
但是这种架构风格并没有很好地处理它的前身SOA遗留的问题，就是如何确定服务的颗粒度，于是，不温不火快10年的DDD派上用场了。DDD这种可以直接按照限界上下文导出数据和行为相结合的设计结果的方法，很适合推微服务一把。Chris Richardson在其著作《微服务架构设计模式》一书中就专门花了两章来介绍DDD与微服务的结合。
在对更快的探索中，敏捷开发、DDD和微服务提供了一种包括软件过程、架构设计和工程实现在内的“组合拳”，当然，这并不意味着所有企业都要这么用，只是一种参考而已。此外，求快的同时，这些方法也都欠缺对企业架构的关注，它们都是可以提升IT开发效能的有力工具，但是，在To B端，仍需要一种可以面向企业级能力建设的方法作为总体导引。
（五）小结：行路难
架构设计的思路到上个世纪70年代才逐渐开始发展出来，软件行业希望也能像工业、建筑业一样具有行业级的设计原则、标准，从而使高质量软件的产出得到保证。但是，到目前为止，架构之路殊为不易，还没有哪种方法升华为举世公认的原则或者榜样。
软件工程到今天才算年过半百，还是个比较年轻的领域。从“瀑布模型”进化到“螺旋模型”大约用了20年；敏捷开发快20岁了，DDD也有17岁；微服务虽然很年轻，才5岁，但是它的前身SOA是1996年诞生的。企业架构从Zachman模型诞生到现在是33岁，而TOGAF到现在也就25岁，只相当于软件工程的一半年纪。如此说来，这些方法以其要服务的目标领域而言，都还是只是刚刚进入“青年”这个水平。
然而上述方法我们至今仍在对其某一方面大加挞伐，没有一个是“银弹”，没有一个不曾被人骂做“坑”。但是贵在探索和坚持，这些方法经历时间的洗礼，仍未褪去“稚嫩”，仍需要“呵护”与反复实践才能健康成长。
现代社会的快节奏对架构的积累确实是一个挑战，“快”原本应该是目标，而今成了方法。我们对很多架构方法的理解尚不深入，对其应用也需要对方法创立者的初衷深加体会，比如，敏捷方法的创始人、“敏捷宣言”起草者之一的Jeff Sutherland在《敏捷革命》一书中提到其灵感来源的“OODA”方法，建议在每个冲刺中都要完整使用，但在各类敏捷书籍中却鲜有提及；Vernon也提到，无论是对敏捷方法还是对DDD而言，“知识获取”都至关重要，但是“知识获取”显然需要积累；即便是对口诛笔伐的“瀑布模型”，也一样存在众多误解。
抛去这些争议不谈，我们至少可以从软件工程与企业架构的发展历程中看到这样两个个趋势：一是关注点从软件架构向企业架构的进化，也就是对软件设计核心目标的认识，软件设计绝不是“先写了再说”，也不一定是越快越好；二是不同方法之间更明显的结合趋势，面向企业的软件设计是一个很复杂的事情，既然很难由某一个方法自己搞定，那就“抱团取暖”吧。
