应用拆分先看业务定位，整合看三个维度反向检验

应用如何拆分没有最佳方案，但有可参考的思路。类比产业链中的企业——很少有企业管理一个产品的全部上下游、即使这样做效率也未必高，产业链里的企业能各司其职，靠的是每个企业都专注于自身的长处（生产要素优势，或技术/业务创新优势），并明确自己在产业链中的定位。所以应用拆分的重要原则是先明确应用自身的定位——这里的定位主要指业务关注点带来的核心位置设定（比如独享的数据或流程）；除了业务关注点，还要考虑技术关注点（技术生命周期、变更频率、弹性要求、高可用要求、安全要求、实时性要求等）；顺序上应该先考虑业务关注点，再考虑技术关注点。整合则可以从三个维度反向检验拆分是否合理：交互维度——上下游应用应尽可能形成单向链路而非网状交互结构，一旦发现交互关系复杂，很可能是拆分不合理造成的；数据维度——要重点关注拆分带来的数据影响，数据分析类的影响较轻（可以靠数据中心/中台集成解决），但实时数据处理类的影响可能严重（应用运行时需要从其他应用实时获取数据，这必然带来数据可用性与一致性之间的冲突，推高系统复杂度和成本）；接口维度——如果一个应用的API调用方很少、或者通常需要跟其他API组合才能提供完整功能，就该考虑这个应用是否需要被整合。拆分和整合本质上相互关联影响：拆分不当必然影响整合效果，整合不合理同样会拖累拆分的效果，两者共同构成应用编排规则。可迁移启发：判断一次应用拆分是不是”拆合理了”，不要只看拆分那一刻的设计文档，而要往后看整合阶段——如果整合时发现交互关系变成了网状、或者实时数据一致性问题频发、或者某个应用的接口老要跟别的接口拼凑着用，这些信号本身就是在反过来告诉你，当初的拆分定位可能没做对。

结构图：

flowchart TB
  S["应用拆分:先业务关注点(核心定位)<br/>再技术关注点(生命周期/弹性/安全等)"]
  S --> I["整合三维度反向检验"]
  I --> I1["交互维度:是否形成单向链路<br/>(网状交互=拆分可能不合理)"]
  I --> I2["数据维度:实时数据一致性冲突程度"]
  I --> I3["接口维度:API调用方是否过少/需拼凑组合"]
  I -.拆分与整合相互影响.-> S