综述

DDD战略篇：架构设计的响应力

作者：肖然

当敏捷宣言的17位签署者在2001年喊出“响应变化胜于遵循计划”这样的口号时，鲜有组织会真正把这句话当回事儿，甚至很多经验丰富的管理者会认为好的计划是成功的一半，遵循计划就是另外一半。然而在时下的第四次工业革命浪潮中，可能很多管理者已经不会简单满足于“响应”，而是选择主动发起变化了。不确定性管理成了这个时代的主旋律，企业的响应力成了成败的关键。

随着这种趋势的深入，架构设计这个技术管理领域也被推到了风暴边缘。“稳定”这个过去我们用来形容好系统的词语似乎已经失去原有的含义，很多人开始用“健壮”这个词语来形容好的系统。比如Netflix公司采用的Chaos Monkey机制随机主动关停线上服务而不会造成整个服务生态宕机的作法更多的是在测试系统的健壮性，保证不会因为某个局部的问题而造成全身瘫痪。

然而架构的健壮性却比较难于定义和测试，以至于很多时候咱们在架构设计上还是在追求稳定性。在一个典型的企业IT组织里，当你询问一位资深工程师架构设计时，往往会得到一张搭积木一样的“架构图”。

图的底层是各种数据存储（从经典的Oracle到大数据标配的Hadoop），图的中间是类似Kafka这样的消息管道和传统的ESB（消息总线），上层则是各种业务应用（包括各种Web应用和移动的APP）。

仿佛这是一个流行的“稳定”架构设计。

（示意：典型的IT系统架构图）

当询问这样的架构是否合理时，不少人会告诉你问题可大了：这不是云时代的服务化架构。原因是这个架构的大部分组件，如数据存储，都已经可以完全“托管”给云平台了。于是乎，很多企业架构师又开始寻找像过去ESB一样能够对接各种云平台的PaaS了，然后抱怨现在的PaaS没有当年的ESB“稳定”。

两个核心问题却很少被提及：

1．当年基于ESB集成的SOA服务化架构解耦出的组件不但没有提升效率，反而增加了系统后续修改的复杂度。

2．看似“以不变应万变”的架构并不能支撑多样化的业务需求，最后各个业务部门仍然有一套自己的IT系统，即

3．画出来的架构图惊人的相似（多少次有人惊呼“这就是我们之前那个工作流系统~”）。

就这两个核心痛点，让我们一起来谈谈架构设计面临的挑战和应对方式。