2. 边界定义的核心原则

在某B2B企业CRM系统改造项目中，“客户管理”模块承载了客户信息、销售线索、合同、服务工单等十余项功能，导致数据混乱、权限失控、一次修改影响8个以上模块。产品经理反馈：“现在改一个字段都要拉6个人评审，开发周期越拖越长。” 这个真实场景揭示了功能边界模糊的典型代价。要根治这类问题，必须从三条核心原则入手：单一职责、高内聚低耦合、可扩展性。

2.1 单一职责原则：让每个模块只做一件事

用户访谈 —— CRM产品经理：“客户管理模块现在什么都有，客户信息、线索、合同、工单全混在一起。每次提需求都要跟开发解释半天‘这个功能到底归谁管’。”

业务问题：一个模块承载超过3个业务子域时，数据一致性、权限模型、变更影响范围都会指数级恶化。在CRM案例中，“客户管理”模块的代码行数超过8万行，涉及12张核心表，任何修改都需要跨团队评审。

需求拆解：将“客户管理”按业务子域拆分为4个独立模块：

• 客户信息管理 — 基础信息增删改查、客户分群、画像标签
• 销售线索管理 — 线索录入、评分、分配、跟进转化
• 合同管理 — 合同创建、审批、履约、变更、终止
• 服务工单管理 — 工单创建、派发、处理、回访、SLA

方案表达：使用功能边界表明确每个模块的“职责范围”与“不做什么”：

2.2 高内聚低耦合：模块内部拧成一股绳，外部只留小接口

用户访谈 —— 开发工程师：“以前改客户模块，要同步修改销售模块、合同模块的代码，因为大家直接读写同一张表。后来加了接口层，改起来才轻松点。” 测试工程师：“回归测试从3天缩短到半天，因为影响范围从8个模块缩小到1-2个。”

业务问题：模块间直接共享数据库表、共用状态变量、存在循环依赖，导致“改一处崩一片”。在CRM案例中，客户信息表和合同表之间存在30+个跨模块触发器，数据一致性难以保障。

需求拆解：从“数据耦合”、“逻辑耦合”、“时序耦合”三个维度评估，识别出6对循环依赖关系，通过引入接口层和数据域事件来切断。

• 数据耦合：模块间只通过API交换数据，不直接读写对方数据表
• 逻辑耦合：模块内部逻辑对外部不可见，通过接口暴露最小能力
• 时序耦合：使用事件驱动替代同步调用的链式依赖

方案表达：模块依赖矩阵（改造前后对比）：

2.3 可扩展性：为未来留好插槽

业务问题：CRM系统上线半年后，业务方提出需要增加“渠道分销”和“大客户专享”两类客户类型，原系统需要修改客户信息管理模块的核心代码，风险极高。

指标验证：可扩展性通过以下量化指标衡量：

• 扩展点密度：每千行代码至少2个预留给业务变化的扩展点
• 新增功能影响范围：新增一个业务类型所需修改的模块数 ≤ 2
• 接口兼容率：新增扩展点时不破坏已有接口契约，兼容率 ≥ 95%

验收标准：

1. 新增“渠道分销客户”类型时，只需在客户信息管理模块中增加一个插件实现，无需修改已有代码。
2. 客户信息查询接口保持向后兼容，原有调用方无需任何调整。
3. 扩展点通过配置文件注册，支持运行时动态加载。
4. 每个模块提供版本化接口，主版本变更需提前一个迭代公告。

2.4 交付物模板：功能边界定义表

以下模板用于每个模块边界定义阶段的交付，需产品经理与架构师共同填写并评审：

将单一职责、高内聚低耦合、可扩展性三条原则