面向业务变化而架构

基于上面的架构设计定义，关键因素就是业务变化。显然这个时代的业务变化是很快的，甚至很多业务主动在变，不变则亡是很多行业目前的共识。变化速度给架构设计带来了很大挑战，一个移动APP可能需要在一周内上线，然而为了支撑这个移动APP的后台服务，平台发布窗口是每两个月一次。这样的不匹配在IT领域里是随处可见的现实，我们习惯性地认为后台天然就很重因此很慢，只可能在牺牲质量的情况下满足这样的速度。

然而事实上这样的健壮架构确实是存在的，看看身边现在无处不在的互联网，又有哪一个企业的架构比之复杂呢。互联网系统的组件是一个个网站，每个网站完成着自己的业务功能更新，从新闻发布到在线聊天。而各个站点又是紧密互联的，聊天网站可能把新闻网站拿到的信息实时推送给在线的用户。每个网站都是独立的小单元，面向互联网用户提供着一定的业务服务。好的网站也根据用户的反馈在不停升级和变化，但这样的变化并不影响用户使用其它的网站。

从互联网架构我们可以学到什么呢？从架构设计角度我认为以下三点是关键。

1．让我们的组件划分尽量靠近变化的原点，对于互联网来说就是用户和业务，这样的划分能够让我们将变化“隔离”在一定的范围（组件）内，从而帮助我们有效减少改变点。

2．组件之间能够互相调用，但彼此之间不应该有强依赖，即各自完成的业务是相对独立的，不会因为一方掉线而牵连另外一方，比如新闻网站挂掉了，聊天网站应该继续正常提供服务，可能提示用户暂时无法提供新闻信息而已。

3．组件在业务上是鼓励复用的，正是这样的复用才成就了今天的互联网，我们不会每个网站都去实现一个强大的搜索引擎。而被“复用”最多的网站显然会受到追捧，成为明星业务。当然架构上这样的网站必然是健壮的。

上面的三点毫无疑问都指向了业务，从业务出发、面向业务变化是我们现代架构设计成功的关键。架构设计的核心实质是保证面对业务变化时我们能够有足够快的响应能力。

这种响应力体现在新需求（变化）的实现速度上，也体现在我们组件的复用上，在实现过程中现有架构和代码变化点的数量也是技术人员能够切身体会到的。面对日新月异的数字化时代，组织的整体关注点都应该集中到变化的原点，即业务上，而架构应该服务于这种组织模式，让这样的模式落地变得自然。

对比之前的传统SOA架构，这个思路的变化是本质性的。类似工业总线（ESB）这样的组件化其实是面向技术的，希望通过技术平台的灵活性来解决业务变化的多样性。虽然短时间能够收到一定的成效，长期看必然把自身做成瓶颈，因为所有业务的变化最后都堆积到了这个技术组件来解决。这也回答了为什么实施了传统SOA架构的企业最后都发现响应速度其实并没有提升起来。

面向业务变化而架构就要求首先理解业务的核心问题，即有针对性地进行关注点分离来找到相对内聚的业务活动形成子问题域。子问题域内部是相对稳定的，即未来的变化频率不会很高，而子问题边界是很容易变化的，比如在一个物流系统中：计算货物从A地到B地的路径是相对固定的，计算包裹的体积及归类也是相对固定的，但根据包裹的体积优化路径却经常会根据业务条件而变化。

（子问题域的划分）