业务与技术的分离，核心与非核心的分离

[[分离性比耦合性更广，源于人类的秩序需求而非计算机需求|分离性]]在代码中的第一类重要体现是业务和技术的分离——二者定位不同（技术服务于业务，业务服务于客户）、领域和生命周期也常常不同步（有时技术需要为业务频繁变更甚至支持多种技术，有时业务快速变化而技术反而不需要变动），因此二者应处在不同轨道上。分离思路有两种：代码分离（业务代码与技术代码泾渭分明，交互时充分封装、限制到最低限度）；依赖分离（不只是代码物理分开，还要确保业务不依赖某项具体技术，通常靠依赖反转实现——反转之前调用流和依赖流都从业务指向技术，技术一变业务就要跟着调整；反转之后保持调用流不变、只反转依赖流，这样技术被替换时业务完全不用修改）。第二类重要体现是业务核心部分与非核心部分的分离——核心部分是系统存在的根基，非核心部分起支撑辅助作用，二者在变化速率等关注点上差异明显（核心更稳定，非核心更灵活）。分离思路有三种：模型分离（把核心部分建模、作为架构资产存储保鲜，从混沌整体中剥离出来，方便后续修改）；模块分离（核心部分独立实现为一个模块，便于独立演进，同时限制模块开放性，只对外暴露必要接口）；依赖分离（同样用依赖反转原则）。可迁移启发：判断一个系统是否做好了这两类分离，可以直接检验——技术选型变了，业务代码要不要跟着改；系统的支撑功能（如日志、监控）要下线或替换，核心业务逻辑会不会被牵连——只要答案是”要跟着改/会被牵连”，说明依赖反转没有真正落地，这两类分离还停留在表面的代码物理分开层面。

结构图：

flowchart TB
  A["业务与技术的分离"]
  A --> A1["代码分离(泾渭分明,交互充分封装)"]
  A --> A2["依赖分离:依赖反转<br/>(调用流不变,反转依赖流→技术替换不影响业务)"]
  B["核心与非核心的分离"]
  B --> B1["模型分离(核心建模,作为架构资产)"]
  B --> B2["模块分离(独立模块,限制开放性,只暴露必要接口)"]
  B --> B3["依赖分离(同样靠依赖反转)"]