还原论的两条通用规则：关注点分离，复制式分离

[[还原论与整体论的核心分歧：整体等于部分之和吗|还原论]]在编程和架构里应用极广——软件工程把大型项目按时间顺序拆成设计/开发/测试等阶段（像流水线）；MVC把应用按业务逻辑/数据/用户界面三维度分层；多线程把大任务拆成子任务并行执行；微服务把大系统拆成多个服务；非功能性需求设计里水平扩容、读写分离、冗余备份也都是还原论的体现。但停留在”用了还原论”这个思想层面还不够，真正有实践指导力的是背后的规则。第一条规则是关注点分离——按某个”关注点”把大个体拆成多个小个体，关注点可以是时间阶段（需求/开发/测试/运维）、角色职责（产品经理/架构师/开发/测试/运维）、功能职责（MVC、微服务的纵向横向拆分）；实践中往往要在不同关注点之间灵活切换，比如投资管理业务先按研究/投资/交易横向拆，再按技术属性拆出通用组件（消息、流程引擎），再按业务通用组件拆（智能报表、风险分析），最后每个领域再按自身特性（如资产类型）继续拆分——抓住关注点就抓住了拆分问题的核心。第二条规则是复制式分离——当一个个体无法满足需求时，”复制”出类似但独立的多份副本，用于提升性能或实现高可用（多线程、读写分离、冗余备份都是这条规则的应用）。结合两条规则可以得到一个系统拆分三维模型：先按技术维度拆（单机多线程/多进程），技术维度不够再按业务和数据维度拆；具体实施顺序上，复制式分离在先、关注点分离在后——先考虑业务水平克隆和数据读写分离，最后才考虑业务垂直拆分和数据分库分表。可迁移启发：一个系统需要扩展时，先检查是否已经把”复制”这条最简单的杠杆用到位（水平扩容、读写分离），再考虑动”关注点分离”这把更复杂的手术刀（业务垂直拆分、分库分表）——顺序反了往往意味着过早引入了不必要的复杂度。

结构图：

flowchart TB
  R["还原论两条规则"]
  R --> C["关注点分离<br/>(时间阶段/角色职责/功能职责)"]
  R --> D["复制式分离<br/>(复制独立副本,提升性能/高可用)"]
  M["系统拆分三维模型"]
  M --> T["技术维度(单机多线程/多进程)"]
  T --> B["业务/数据维度<br/>先复制式分离(水平克隆/读写分离)<br/>再关注点分离(垂直拆分/分库分表)"]