用平衡耦合模型评估代码模块化并定位重构机会

在评审代码架构、重构模块或设计新系统时，用平衡耦合模型分析耦合强度、connascence 类型与距离，找出问题耦合并给出重构方案。

适用场景

解决思路

1. 按三个维度评估耦合：集成强度（共享了什么知识）、距离（知识传播多远）、易变性（变更频率）。
2. 判断集成强度，从强到弱分为：Intrusive（使用非公开接口，如直接访问其他服务的数据库、反射访问私有字段）、Functional（共享业务逻辑/规则，如重复的校验、依赖顺序的操作）、Model（共享领域模型，如两个服务使用相同实体定义）、Contract（仅显式接口，如设计良好的 API、DTO、协议）。
3. 判断距离，从近到远依次为：同一类内的方法、同一文件内的类、同一命名空间/包内的类、不同命名空间的模块、独立服务/微服务、不同团队拥有的服务、不同系统/组织。
4. 判断易变性，用 DDD 子域分类：Core 子域高易变（竞争优势、频繁变更）、Supporting 子域低易变（必要但非差异化）、Generic 子域低易变（已解决问题、稳定）。
5. 套用决策矩阵：高强度+高距离=复杂度（分布式单体）；低强度+低距离=复杂度（不必要的抽象）；高强度+低距离=模块化（相关内容放一起）；低强度+高距离=模块化（独立组件分开）。
6. 若易变性低，则耦合不匹配可接受。
7. 用 connascence 识别具体耦合类型。静态 connascence（编译期，较易修复）从弱到强：Name (CoN) 名称一致、Type (CoT) 类型一致、Meaning (CoM) 值含义一致（魔法数字）、Position (CoP) 值顺序一致、Algorithm (CoA) 共享算法逻辑。
8. 动态 connascence（运行期，较难发现）从弱到强：Execution (CoE) 方法调用顺序重要、Timing (CoTm) 执行时机重要、Value (CoV) 多个值必须一起变更、Identity (CoI) 必须引用同一实例。
9. 遵循 connascence 规则：最小化整体 connascence；最小化跨模块边界的 connascence；最大化模块边界内的 connascence；把更强的 connascence 转换为更弱形式；距离增大时 connascence 应减弱。
10. 检查红旗（需立即处理）：直接访问其他服务数据库（Intrusive 耦合）、反射访问私有字段、业务逻辑跨服务重复、微服务需要同步部署、类的 CBO（Coupling Between Objects）> 14、频繁变更模块的不稳定指数在 0.3-0.7、模块间循环依赖。
11. 检查警告信号（需进一步调查）：组件间共享魔法数字/值（CoM）、API 中依赖位置的参数（CoP）、算法逻辑多处重复（CoA）、方法必须按特定顺序调用（CoE）、长方法链 a.b().c().d()（违反 Law of Demeter）、承担过多职责的 Manager/Helper/Utility 类。
12. 确认健康模式：服务间基于 Contract 的集成、真正抽象内部模型的 DTO、模块内高内聚、每个类单一职责、对外部依赖使用依赖注入。
13. 按集成强度问题重构：Intrusive→Contract：识别所有对实现细节的直接依赖，定义显式接口/契约，创建适配层，让所有访问经过适配层。
14. Functional→Model：把共享业务逻辑抽取到专门模块，定义清晰归属，通过显式依赖消费。
15. Model→Contract：创建集成专用 DTO，在边界处映射内部模型与 DTO，让契约独立于模型进行版本管理。
16. 按 connascence 类型重构：CoM→CoN 用命名常量/枚举替换魔法值；CoP→CoN 用命名参数、builder 模式或参数对象；CoA→CoN 把算法抽取到单一位置并按名称引用；CoT→CoN 用 duck typing 或接口；CoE→显式 用状态机、builder 模式或构造器注入；CoI→显式 用依赖注入并显式装配。
17. 按距离问题重构：高强度+高距离（分布式单体）可选 A 减小距离（合并服务/模块）或 B 降低强度（引入契约、异步消息）；低强度+低距离（过度抽象）则移除不必要的抽象层、内联过度通用的代码、合并紧密相关的类。
18. 按分析工作流执行：1) 映射组件结构，识别模块/服务/类并画依赖图；2) 评估集成强度，对每个依赖分类并标记高强度跨边界依赖；3) 测量距离，记录组件位置与团队/归属边界；4) 评估易变性，分类子域类型并标注历史上频繁变更的区域；5) 套用公式，检查强度与距离是否匹配、易变性是否可解释不匹配；6) 识别 connascence，扫描具体类型并按高强度+低局部性+高程度优先排序；7) 按影响与成本排序给出具体重构技术建议。
19. 按指定输出格式给出评估：Modularization Assessment（Summary、Component Map、Coupling Analysis 表格含 Component Pair/Strength/Distance/Volatility/Balance、Connascence Issues、Recommendations 按优先级、Refactoring Plan 针对最高优先级项的分步方案）。

适用边界 · 注意事项

• 无法在没有执行上下文的情况下评估运行时行为。
• 易变性评估需要领域知识，团队/组织距离需要项目上下文，历史变更频率无法仅靠静态分析获得。