虚拟业务域：分久必合，用网关Facade收编子系统爆炸

互联网的业务千差万别，不同业务分解下来对应不同的子系统，所以业务层没办法像用户层那样提炼出公共组件。抛开具体业务差异，各互联网业务发展最终面临的问题都类似：业务复杂度越来越高，而复杂度越来越高的一个主要原因就是系统越来越庞大、业务越来越多。应对业务层复杂度的核心方法只有一把”屠龙宝刀”——”拆”，化整为零、分而治之，把整体复杂性分散到多个子业务或子系统里（具体拆的方式即分层架构、微服务、微内核等）。以一个电商系统为例：第一阶段所有功能都在一个系统里；第二阶段拆分成商品、订单两个子系统；第三阶段商品子系统和订单子系统又分别拆成更小的共6个子系统。这只是样例，实际业务发展中子系统会越来越多，据说淘宝内部大大小小的子系统已经有成百上千个。但当子系统数量拆到几百上千时，另一个复杂度问题会凸显出来：系统数量太多，已经没有人能说清楚业务的完整调用流程了，出问题排查也会特别复杂——此时不可能把子系统再合并回大系统（那样又会回到最初的问题），真正的答案还是”合”，正所谓”合久必分、分久必合”，但这次”合”的方式不一样：按照”高内聚、低耦合”的原则，把职责关联比较强的一组子系统合成一个”虚拟业务域”，然后通过网关对外统一呈现——本质上类似设计模式中的Facade（外观）模式：把一堆职责相关的子系统包装在网关背后，对外部调用方呈现出一个统一、简化的接口，调用方无需感知域内部具体有多少个子系统、调用链路如何流转。

结构图：

flowchart TB
  A["业务复杂度持续上升<br/>根源：系统越来越庞大、业务越来越多"]
  A --> B["核心方法：拆<br/>(分层架构/微服务/微内核)"]
  B --> C["电商样例：1个系统→商品/订单2个子系统<br/>→进一步拆成6个子系统"]
  C --> D["子系统拆到成百上千个<br/>新问题：调用流程无人能说清，排查困难"]
  D --> E["合久必分、分久必合<br/>但这次'合'不是合并回大系统"]
  E --> F["按高内聚低耦合原则<br/>把职责相关的子系统合成'虚拟业务域'"]
  F --> G["网关对外统一呈现<br/>=Facade模式：对外一个接口，内部细节被屏蔽"]