（四）对更快的探索：敏捷开发、DDD和微服务
对效率的探索涌现出了更多的软件工程方法、设计方法，不同方法间逐渐形成组合，从单一方法到“组合拳”也是一个很有意思的过程。
不满足于软件工程的进步，90年代，敏捷开发的思路开始出现。2001年，在美国犹他州雪鸟滑雪胜地，敏捷方法发起者组织敏捷聚会并起草大名鼎鼎的《敏捷宣言》，“敏捷”开发也在这次聚会上正式定名。虽然目前对敏捷开发的认识还不是很一致，但大体上的开发流程，可以在网上找到很多类似图3的介绍：
敏捷开发的矛头可谓直指“瀑布模型”，大多数讲敏捷开发的书几乎都以此开头。笔者并非一个敏捷实践者，因此也无法深入讨论这一方法的优缺点，但是从对其实现过程的介绍来看，企业架构的设计显然没有包含在敏捷过程中，敏捷强调的是产品和用户维度，而且敏捷的“轻文档”理念与企业架构已有的“重文档”方法之间也是有矛盾的。
由于研究的人很多，敏捷开发在软件过程管理和软件设计方面都有较快发展。尽管有人质疑其效果，但是据称全球排名第11的资产管理公司——荷兰国际集团（ING）是在全公司推行敏捷开发的，该公司拥有员工113,000人，在全球50个国家为6千多万客户提供金融服务。
除了对过程的加速，架构设计方法本身也有创新。2003年，Eric Evans提出了DDD，也即领域驱动设计方法，该方法的特点是在需求分析、软件设计方面的一体化实现，通过领域模型直接形成可以指导到“类”设计的软件架构模型。但是DDD明显只是一个软件架构设计方法，而非企业架构设计，并且，DDD领域的大师级人物Vaughn Vernon认为企业级是无法从顶层直接设计的，只能在领域建模完成后，逐个领域地进行尝试性融合。Eric Evans也在其书的结尾对“总体规划”方法表示了一种委婉的不信任。DDD最经典的架构图如图4和图5所示：
EricEvans曾提出该方法主要面向敏捷过程，二者其实在方法层面有相似之处，都强调快速由需求进入开发过程，也都注重对模式的运用。但是因为DDD方法掌握起来有一定难度，因此并没有真的随着敏捷开发“火”起来，倒是借了另一种架构风格的“东风”，微服务。
微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格注重用具备独立数据库的微服务来替代原有的单体应用设计方式，每个微服务运行在自己的进程中，并使用轻量级机制通信，通常是Restful API。这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，服务可以使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。从理念上看，极具灵活性、快速响应能力、可复用性和扩展性，案例上更是有传奇公司Netflix做标杆。
但是这种架构风格并没有很好地处理它的前身SOA遗留的问题，就是如何确定服务的颗粒度，于是，不温不火快10年的DDD派上用场了。DDD这种可以直接按照限界上下文导出数据和行为相结合的设计结果的方法，很适合推微服务一把。Chris Richardson在其著作《微服务架构设计模式》一书中就专门花了两章来介绍DDD与微服务的结合。
在对更快的探索中，敏捷开发、DDD和微服务提供了一种包括软件过程、架构设计和工程实现在内的“组合拳”，当然，这并不意味着所有企业都要这么用，只是一种参考而已。此外，求快的同时，这些方法也都欠缺对企业架构的关注，它们都是可以提升IT开发效能的有力工具，但是，在To B端，仍需要一种可以面向企业级能力建设的方法作为总体导引。
