当敏捷宣言的17位签署者在2001年喊出“响应变化胜于遵循计划”这样的口号时，鲜有组织会真正把这句话当回事儿，甚至很多经验丰富的管理者会认为好的计划是成功的一半，遵循计划就是另外一半。然而在时下的第四次工业革命浪潮中，可能很多管理者已经不会简单满足于“响应”，而是选择主动发起变化了。不确定性管理成了这个时代的主旋律，企业的响应力成了成败的关键。
随着这种趋势的深入，架构设计这个技术管理领域也被推到了风暴边缘。“稳定”这个过去我们用来形容好系统的词语似乎已经失去原有的含义，很多人开始用“健壮”这个词语来形容好的系统。比如Netflix公司采用的Chaos Monkey机制随机主动关停线上服务而不会造成整个服务生态宕机的作法更多的是在测试系统的健壮性，保证不会因为某个局部的问题而造成全身瘫痪。
然而架构的健壮性却比较难于定义和测试，以至于很多时候咱们在架构设计上还是在追求稳定性。在一个典型的企业IT组织里，当你询问一位资深工程师架构设计时，往往会得到一张搭积木一样的“架构图”。
图的底层是各种数据存储（从经典的Oracle到大数据标配的Hadoop），图的中间是类似Kafaka这样的消息管道和传统的ESB（消息总线），上层则是各种业务应用（包括各种Web应用和移动的APP）。
仿佛这是一个流行的“稳定”架构设计。
（示意：典型的IT系统架构图）
当询问这样的架构是否合理时，不少人会告诉你问题可大了：这不是云时代的服务化架构。原因是这个架构的大部分组件，如数据存储，都已经可以完全“托管”给云平台了。于是乎，很多企业架构师又开始寻找像过去ESB一样能够对接各种云平台的PaaS了，然后抱怨现在的PaaS没有当年的ESB“稳定”。
两个核心问题却很少被提及：
- 当年基于ESB集成的SOA服务化架构解耦出的组件不但没有提升效率，反而增加了系统后续修改的复杂度。
- 看似“以不变应万变”的架构并不能支撑多样化的业务需求，最后各个业务部门仍然有一套自己的IT系统，即便是画出来的架构图惊人的相似（多少次有人惊呼“这就是我们之前那个工作流系统~”）。
就这两个核心痛点，让我们一起来谈谈架构设计面临的挑战和应对方式。
什么是架构设计
由于软件设计是一个复杂度很高的活动，“通过组件化完成关注点分离从而降低局部复杂度”很早就成为了咱们这个行业的共识。前面提到的数据存储、消息管道等“模块”在某种意义上都是组件化的产物。这样的好处是在不同系统里遇到同样的功能需求时可以复用。在云服务崛起的今天，这样的组件以“服务”的形式更容易为我们所采用。
当然技术出身的架构师们在架构设计的时候或多或少都有一种“搭积木”的感觉。大家都非常关注Kafaka有哪些功能，K8S是不是比Mesos功能更全，以及Akka是不是稳定。就像走进一个家装公司，在选择了“套餐”之后有工程人员给你介绍地砖和木地板用哪个品牌更好。
回到咱们的第二个核心痛点，如果只是这样的搭积木，为什么咱们总是在面对新变化、新需求的时候发现需要新的组装方式或新的组件呢？这样的架构设计对比直接按照需求实现（不考虑架构）有什么优势呢？
这里我们应该回到架构设计的本质，即为什么我们要在代码实现前做设计。显然如果去掉设计这个过程，大家会说问题这么复杂，如何下手啊？所以设计首先是要解决问题的复杂度。于是有人做了一个架构，交给了一个团队去实现，很快发现实现的架构和设计完全是两张皮。当然原因很明确——缺少了交流和沟通，所以设计其次是要建立团队协作沟通的共识。
假设我们产生了一个团队都达成共识的架构设计，大家都兢兢业业把设计变成了现实。一个长期困扰软件行业的问题出现了，需求总是在变化，无论预先设计如何“精确”，总是发现下一个坑就在不远处。相信很多技术人员都有这样的经历，结果往往是情况越来越糟糕，也就是我们常说的架构腐化了，最后大家不得不接受重写。这些经历让我们逐步明确了软件架构设计的实质是让系统能够更快地响应外界业务的变化，并且使得系统能够持续演进。在遇到变化时不需要从头开始，保证实现成本得到有效控制。
面向业务变化而架构
基于上面的架构设计定义，关键因素就是业务变化。显然这个时代的业务变化是很快的，甚至很多业务主动在变，不变则亡是很多行业目前的共识。变化速度给架构设计带来了很大挑战，一个移动APP可能需要在一周内上线，然而为了支撑这个移动APP的后台服务，平台发布窗口是每两个月一次。这样的不匹配在IT领域里是随处可见的现实，我们习惯性地认为后台天然就很重因此很慢，只可能在牺牲质量的情况下满足这样的速度。
然而事实上这样的健壮架构确实是存在的，看看身边现在无处不在的互联网，又有哪一个企业的架构比之复杂呢。互联网系统的组件是一个个网站，每个网站完成着自己的业务功能更新，从新闻发布到在线聊天。而各个站点又是紧密互联的，聊天网站可能把新闻网站拿到的信息实时推送给在线的用户。每个网站都是独立的小单元，面向互联网用户提供着一定的业务服务。好的网站也根据用户的反馈在不停升级和变化，但这样的变化并不影响用户使用其它的网站。
从互联网架构我们可以学到什么呢？从架构设计角度我认为以下三点是关键。
- 让我们的组件划分尽量靠近变化的原点，对于互联网来说就是用户和业务，这样的划分能够让我们将变化“隔离”在一定的范围（组件）内，从而帮助我们有效减少改变点。
- 组件之间能够互相调用，但彼此之间不应该有强依赖，即各自完成的业务是相对独立的，不会因为一方掉线而牵连另外一方，比如新闻网站挂掉了，聊天网站应该继续正常提供服务，可能提示用户暂时无法提供新闻信息而已。
- 组件在业务上是鼓励复用的，正是这样的复用才成就了今天的互联网，我们不会每个网站都去实现一个强大的搜索引擎。而被“复用”最多的网站显然会受到追捧，成为明星业务。当然架构上这样的网站必然是健壮的。
上面的三点毫无疑问都指向了业务，从业务出发、面向业务变化是我们现代架构设计成功的关键。
架构设计的核心实质是保证面对业务变化时我们能够有足够快的响应能力。
这种响应力体现在新需求（变化）的实现速度上，也体现在我们组件的复用上，在实现过程中现有架构和代码变化点的数量也是技术人员能够切身体会到的。面对日新月异的数字化时代，组织的整体关注点都应该集中到变化的原点，即业务上，而架构应该服务于这种组织模式，让这样的模式落地变得自然。
对比之前的传统SOA架构，这个思路的变化是本质性的。类似工业总线（ESB）这样的组件化其实是面向技术的，希望通过技术平台的灵活性来解决业务变化的多样性。虽然短时间能够收到一定的成效，长期看必然把自身做成瓶颈，因为所有业务的变化最后都堆积到了这个技术组件来解决。这也回答了为什么实施了传统SOA架构的企业最后都发现响应速度其实并没有提升起来。
面向业务变化而架构就要求首先理解业务的核心问题，即有针对性地进行关注点分离来找到相对内聚的业务活动形成子问题域。子问题域内部是相对稳定的，即未来的变化频率不会很高，而子问题边界是很容易变化的，比如在一个物流系统中：计算货物从A地到B地的路径是相对固定的，计算包裹的体积及归类也是相对固定的，但根据包裹的体积优化路径却经常会根据业务条件而变化。
（子问题域的划分）
面对业务的变化也要求我们的架构必须是演进的，因为业务的变化点也会随着时间推移发生着变化。这意味着在一款较长生命周期的软件产品中，不会出现类似ESB这样的重型组件，相反的我们追求的是一些面向业务服务的轻量级组件，它们的持续演进也会造成老组件的合并，新组件的重新拆分。当然这也成了现代微服务架构成功的基础条件之一。
打造架构响应力的方法
如果认同了上述现代架构的真正意义，大家一定会问怎么才能打造这样的高响应力架构呢？
领域驱动设计方法DDD（Domain Driven Design）为我们提供了很好的切入点。这个2003年就总结出来的方法终于在10多年后重新走入了架构师的视野，而这一次大家已经意识到了这种方法在这个快速变化时代的重要性。DDD通过以下两个模式去有效解决了文章开始提到的两大痛点：
- 让团队中各个角色（从业务到开发测试）都能够采用统一的架构语言，从而避免组件划分过程中的边界错位。
- 让业务架构和系统架构形成绑定关系，从而建立针对业务变化的高响应力架构。
这两点是DDD的核心，也是为什么时下全球架构圈在进一步向DDD这个方向靠拢的原因。DDD明确了业务和系统架构上的绑定关系，并提供了一套元语言来帮助各个角色有效交流架构设计。
（DDD的基本方法）
在战略层面，DDD非常强调针对业务问题的分析和分解，通过识别核心问题域来降低分析的复杂度。在战术层面，DDD强调通过识别问题域里的不同业务上下文来进行面向业务需求的组件化。最后在实现层面利用成熟的技术模式屏蔽掉技术细节的复杂度。
在这里我们也希望通过第一届DDD China建立起一个架构设计人员的交流平台。期待更多的中国技术人员能够通过这个平台和世界一流架构大师们建立起沟通的渠道，不仅在战略层面，也在战术层面和所有人一起分享讨论关于DDD的一切。
更多精彩洞见，请关注微信公众号：思特沃克
WeChatSina WeiboEvernotePocketInstapaperEmail LinkedInPinterest
