第 9 章：拆还是合

系列：软件设计的哲学 · 第 9/22 章
全书导读：00-overview.md

一句话总结

合并或拆分模块的准则不是「类要小」，而是能否降低整体复杂度——常合在「一起更简」，常拆在「彼此独立」。

第 9 章收束第 4–8 章的横向结构议题，与第 7 章纵向分层互补。之后第 10–11 章转向错误定义与设计过程。

FITMeServiceRequest 与 FITMeServiceManager 若永远同生共死、共享状态机，评估是否合并为单一深模块，减少跨类同步。反之，纯网络层与业务编排若生命周期不同，应保持拆分。

重点：拆合的唯一标准是复杂度增减，非 SOLID 字母游戏。
重点：合并浅模块常能加深整体——一个深入口胜过两个浅入口。
注意：团队边界、微服务时尚不是拆的理由。
注意：大模块内用子模块 / 命名空间保持可读，勿一步到位微服务。