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