模块划分方法：业务域分析、功能拆分、数据依赖分析、模块粒度确定、模块边界划分
模块划分是开发方案模块化的核心工序，决定了后续开发、测试、集成与维护的效率和成本。一个合理的模块划分方案，既要反映业务逻辑的完整性，又要兼顾技术实现的可行性与团队协作的便利性。本章围绕五步法展开：业务域分析、功能拆分、数据依赖分析、模块粒度确定、模块边界划分，形成一套可落地的操作路径。
4.1 业务域分析：从业务能力地图出发
核心原理
业务域分析是模块划分的起点，其本质是将业务需求映射为业务能力地图。业务域（Business Domain）是业务活动的逻辑分组，每个域代表一组高内聚的业务能力。例如，在电商系统中，商品管理、订单处理、支付结算、用户管理、库存管理、物流配送等各自构成一个业务域。业务域分析的目标是回答"业务要做什么"，而非"系统怎么实现"。
业务域分析通常采用领域驱动设计（DDD）中的限界上下文（Bounded Context）思想，将业务划分为多个上下文，每个上下文拥有独立的业务模型和术语。限界上下文之间的交互通过上下文映射（Context Mapping）来定义，包括共享内核（Shared Kernel）、客户-供应商（Customer-Supplier）、防腐层（Anti-Corruption Layer）等模式。
判断方法与操作流程
- 收集业务资料：包括业务流程图、用例文档、需求规格说明书、用户访谈记录等。
- 识别业务事件：列出业务生命周期中的关键事件，如"订单已创建""支付已确认""库存已扣减"。
- 绘制业务能力地图：将业务事件按业务域归类，形成能力地图。每个能力点标注业务价值、使用频率、变更频率。
- 验证域边界：检查每个域是否具有独立的业务目标、独立的术语表、独立的业务规则。
| 业务域 | 核心能力 | 关键业务事件 | 独立术语 |
|---|---|---|---|
| 商品域 | 商品上架、价格管理、类目管理 | 商品创建、价格变更 | SKU、SPU、类目 |
| 订单域 | 购物车、下单、订单状态流转 | 订单创建、订单取消 | 订单号、订单项、支付状态 |
| 支付域 | 支付发起、支付回调、退款 | 支付成功、退款完成 | 交易号、支付渠道、对账单 |
| 库存域 | 库存查询、库存扣减、库存预警 | 库存锁定、库存释放 | 库存量、锁定库存、安全库存 |
案例拆解：某零售企业订单履约系统
某零售企业计划重构其订单履约系统，原系统为单体架构，订单、库存、支付、物流逻辑全部耦合在一个应用中。团队首先进行业务域分析：通过一周的访谈和事件风暴，识别出订单域、库存域、支付域、履约域、客户域五个业务域。关键发现是"履约域"（包括拣货、打包、出库、配送）在原系统中被分散在订单和库存逻辑中，导致每次物流规则调整都要改动订单核心代码。通过业务域分析，团队将履约独立为域，为后续模块划分奠定了基础。
4.2 功能拆分：从用例到功能点
核心原理
功能拆分是在业务域确定之后，将每个域内的功能进一步细化为可独立开发、测试的功能单元。功能拆分遵循"单一职责"原则，每个功能点应具有明确的输入、处理逻辑和输出。功能拆分不是越细越好，而是以"可独立交付价值"为基准。
判断方法与操作流程
- 基于用例拆分：每个用例（Use Case）对应一个用户目标，可拆分为一个或多个功能点。例如"用户下单"用例可拆分为"创建订单""校验库存""计算价格""生成订单号"等功能点。
- 基于用户故事拆分：在敏捷开发中，用户故事可按INVEST原则（Independent, Negotiable, Valuable, Estimable, Small, Testable）拆分。一个大型用户故事拆分为多个小故事，每个故事可独立交付。
- 基于业务流程拆分：按业务流程的步骤拆分功能点，每个步骤对应一个功能。例如"退货流程"可拆分为"退货申请""退货审核""退货收货""退款处理"。
- 每个功能点是否有明确的输入/输出？
- 每个功能点是否可独立测试？
- 每个功能点是否可由一个团队独立开发？
- 功能点之间是否存在循环依赖？
- 功能点的命名是否业务可理解？
常见误区
功能拆分最常见的误区是"过度拆分"——将原本一个完整的功能拆成十几个细碎的功能点，导致模块数量爆炸、接口数量剧增、集成成本上升。另一个误区是"拆分粒度不均"——有的功能点极大（包含大量逻辑），有的功能点极小（仅一行代码），导致开发工作量估算失真。建议使用功能点分析法（FPA）或故事点估算来校准拆分粒度。
4.3 数据依赖分析：识别耦合根源
核心原理
数据依赖分析是模块划分中最关键的技术环节。模块之间的耦合，本质上是数据依赖的耦合。如果两个模块共享同一张数据库表、同一个缓存键或同一个文件，它们就存在数据依赖。数据依赖分析的目标是识别这些依赖关系，并决定是"共享"还是"隔离"。
操作流程
- 绘制实体关系图（ERD）：列出所有业务实体及其关系，标注每个实体的归属域。
- 分析数据流向：追踪数据在功能点之间的流动路径，识别跨域数据访问。
- 识别共享数据：找出被多个功能点读写的表、缓存、文件、消息队列。
- 评估依赖强度：区分强依赖（同步调用、事务性读写）和弱依赖（异步通知、最终一致性）。
| 依赖类型 | 示例 | 耦合强度 | 处理策略 |
|---|---|---|---|
| 共享表 | 订单表和支付表共用同一数据库 | 高 | 按域拆分表，通过接口交互 |
| 共享缓存 | 商品信息和库存信息共用同一Redis键空间 | 中 | 缓存按域隔离，使用不同前缀 |
| 消息队列 | 订单创建后发送MQ消息给库存和支付 | 低 | 保留异步解耦，定义消息契约 |
| 共享文件 | 多个模块读写同一份配置文件 | 中 | 配置中心统一管理，按域分组 |
4.4 模块粒度确定：高内聚与低耦合的权衡
核心原理
模块粒度是指模块的大小和职责范围。粒度过大，模块内部逻辑复杂，难以维护和测试；粒度过小，模块数量过多，接口管理和部署成本上升。模块粒度确定的核心原则是"高内聚、低耦合"，但具体粒度需要根据团队规模、技术栈、业务复杂度综合判断。
粒度评估维度
- 团队规模：每个模块应有明确的负责人（或团队），模块数量不宜超过团队数量的3-5倍。
- 变更频率：变更频繁的功能应独立成模块，避免影响稳定模块。
- 复用需求：被多个上层模块复用的功能应独立为底层模块。
- 部署需求：需要独立扩缩容的模块应独立拆分。
粒度确定方法
推荐使用"粒度评分卡"进行量化评估。对候选模块从内聚度（1-5分）、耦合度（1-5分，越低越好）、可测试性（1-5分）、可复用性（1-5分）、部署独立性（1-5分）五个维度打分，总分超过20分的候选模块可保留，低于15分的需要合并或拆分。
- 模块代码超过1万行 → 考虑拆分
- 模块接口超过20个 → 考虑拆分
- 模块依赖超过5个其他模块 → 考虑合并或重构
- 模块内功能点之间无业务关联 → 考虑拆分
4.5 模块边界划分：定义接口与依赖方向
核心原理
模块边界划分是模块划分的收口步骤，需要明确每个模块的对外接口、依赖方向、数据所有权和异常处理策略。边界划分的核心是"依赖倒置"——上层模块依赖抽象接口，而非底层模块的具体实现。同时，模块之间的依赖方向应形成有向无环图（DAG），避免循环依赖。
边界划分规则
- 接口先行：先定义模块间的接口契约（包括数据结构、错误码、超时时间、幂等性要求），再实现模块内部逻辑。
- 单向依赖：模块A依赖模块B，则B不能依赖A。如果出现双向依赖，应引入中间层或事件机制解耦。
- 数据归属：每个数据实体只能由一个模块拥有写权限，其他模块通过接口读写。
- 异常隔离：模块间的异常应通过错误码或异常类型传递，不允许跨模块抛出未捕获的运行时异常。
案例拆解：订单模块与库存模块的边界设计
在订单履约系统中，订单模块需要扣减库存。初始设计是订单模块直接调用库存模块的扣减接口，但库存模块又需要查询订单状态来释放锁定库存，形成循环依赖。解决方案是引入"库存预留"概念：订单模块调用库存模块的"预留库存"接口，库存模块返回预留凭证；订单确认后，订单模块发送"确认扣减"事件，库存模块监听事件完成扣减。这样依赖方向变为：订单模块 → 库存模块（预留接口），库存模块 → 消息队列（监听事件），订单模块 → 消息队列（发送事件），消除了循环依赖。
| 边界设计要素 | 订单模块 | 库存模块 |
|---|---|---|
| 对外接口 | 创建订单、查询订单、取消订单 | 预留库存、释放预留、查询库存 |
| 数据所有权 | 订单表、订单项表 | 库存表、库存流水表 |
| 依赖方向 | 依赖库存模块接口、消息队列 | 依赖消息队列（监听事件） |
| 异常处理 | 库存预留失败→订单创建失败 | 预留超时→自动释放 |
4.6 模块划分的常见误区与复盘
误区一：以技术分层代替业务域划分
有些团队将模块划分为"控制层""服务层""数据访问层"，这种技术分层是必要的，但不能替代业务域划分。正确的做法是"业务域为主、技术层次为辅"——每个业务域内部再按技术层次组织代码。
误区二：忽略数据迁移成本
模块划分往往涉及数据库表拆分，而数据迁移的成本和风险常被低估。在划分模块前，应评估数据迁移的可行性，必要时采用"先逻辑拆分、后物理拆分"的策略，先通过视图或中间层隔离，再逐步迁移数据。
误区三：追求完美划分而延误交付
模块划分没有的最优解，过度追求完美会导致分析瘫痪。建议采用"演进式划分"——先按当前业务理解划分，在迭代中根据实际反馈调整。每次调整应记录原因和影响，形成架构决策记录（ADR）。
复盘清单
- 模块划分是否支持业务快速响应？
- 模块间的接口是否稳定且文档完备？
- 数据依赖是否清晰且可控？
- 团队是否清楚自己负责的模块边界？
- 模块划分是否支持未来的业务扩展？
模块划分方法不是一次性的活动，而是贯穿项目生命周期的持续优化过程。业务域分析提供业务视角，功能拆分细化功能单元，数据依赖分析揭示技术耦合，模块粒度确定平衡复杂度，模块边界划分固化架构决策。五步法环环相扣，每一步的输出都是下一步的输入，最终形成一套清晰、可执行、可演进的模块化方案。