Module vs Bounded Context = 何时升级到独立 BC

一、业务问题

Module 和 Bounded Context 都是组织代码的方式，但有本质区别：

• Module = 代码内命名空间（Java package / C# namespace）
• Bounded Context = 独立部署的模型边界

关键问题：何时用 Module，何时升级到 Bounded Context？

二、控制论视角

Module = 控制系统的内部结构
Bounded Context = 独立控制系统的边界

类比：
  - Module = 一个系统的内部模块
  - BC = 独立系统
  - 升级 = 内部模块 → 独立系统
  
钱学森 Ch 21：
  - 内部模块化 = 集中系统的清晰划分
  - 独立 BC = 多级分散系统

Vernon 在 Ch 9 明确区分两种模块。

三、两种模块的本质

3.1 传统模块（代码层）

Module = 命名容器
  - Java: package
  - C#: namespace
  - Ruby: module
  - 作用：组织代码
  - 特点：编译时
  - 边界：代码文件

3.2 部署模块（运行时）

Module = 部署单元
  - 微服务
  - jar / war
  - 容器
  - 作用：独立部署
  - 特点：运行时
  - 边界：进程/容器

3.3 Bounded Context

Bounded Context = 模型边界
  - 一个模型 = 一个 BC
  - 一个团队 = 一个 BC（理想）
  - 一个部署 = 一个 BC
  - 一套通用语言 = 一个 BC

关键区别：

• Module = 代码组织
• BC = 模型 + 团队 + 部署

四、何时用 Module vs BC

4.1 用 Module（不升级到 BC）

适用：
  - 内部代码组织
  - 团队 < 5 人
  - 模型简单
  - 业务内聚
  - 单一部署
  
不适用：
  - 业务独立演化
  - 团队独立
  - 部署独立

4.2 升级到 Bounded Context

判断标准（满足任一即升级）：
  □ 业务独立演化（变更频率不同）
  □ 团队独立（不同小组负责）
  □ 部署独立（不同节奏）
  □ 数据可最终一致
  □ 跨团队协作
  
  ≥ 2 个 ✓ → 升级到 BC

4.3 何时不升级

反模式：
  - 频繁跨 BC 调用
  - 强一致事务
  - 团队小（< 5 人）
  - 业务高度耦合
  
即使技术允许，也保持 Module

五、演进路径

Phase 1：单部署，模块化代码
  - 一个 BC = 一个 Module
  - 内部按业务分 package
  
Phase 2：单部署，多个 Module
  - 多个 BC = 多个 Module
  - 仍单部署
  - 编译期隔离
  
Phase 3：多部署，多个 BC
  - 多个 BC = 多个微服务
  - 独立部署
  - 进程隔离
  
Phase 4：服务网格
  - 多个 BC + 边车
  - 统一治理
  - 动态路由

六、工程实践

实战 1：识别 BC 升级时机

信号：
  - 一个 Module 经常被多个团队改
  - Module 部署时间太长
  - Module 业务边界模糊
  - Module 间频繁调用
  
→ 考虑升级到独立 BC

实战 2：避免过早拆分

反模式：
  - 业务刚起步就拆 5 个微服务
  - 团队只有 3 人但有 5 个 BC
  - 业务紧密耦合但强行解耦
  
正模式：
  - 业务稳定后再拆
  - 团队规模 > 5 后拆
  - 业务可独立演化才拆

实战 3：Module 命名

好命名（业务化）：
  - ordermanagement
  - shippinglogistics
  - billinginvoicing
  
坏命名（技术化）：
  - entities（无业务感）
  - services（太通用）
  - utils（废物堆）
  - helpers（更通用）

七、性能指标

指标	衡量
BC 数量	多少个 BC（应该按需）
Module 数量	多少个 Module（应该 = BC × 内部分层）
跨 BC 调用	多少跨 BC 调用（应该 < 5%）
独立部署频率	各 BC 部署频率（应该不同）

八、边界判断

何时用 Module：

• 内部代码组织
• 业务内聚的概念集合
• 团队 < 5 人

何时升级到 Bounded Context：

• 业务独立演化
• 团队独立
• 部署独立
• 数据可最终一致

何时合并 Module/BC：

• 频繁跨域调用
• 几乎不独立演化
• 业务高度耦合

九、与其他 L 层方法论的关系

方法论	关系
bounded-context	BC 是 Module 的升级版
problem-vs-solution	Module 是问题空间的代码化
package-structure	Module 的具体代码组织
subdomain	子域 → BC 决策

十、钱学森原话

Ch 21 §21.3（系统划分）： "大系统的特点是规模庞大、结构复杂、目标多样"——BC 是"目标多样"的工程实现。

Ch 6 §6.7（耦合取舍）： "有些耦合作用是有益的"——不要为了解耦而解耦。

十一、总结

Module vs Bounded Context = 何时升级到独立 BC：

维度	Module	Bounded Context
边界	代码文件	进程/部署
团队	共享	独立
演化	一起	独立
数据	共享	可独立

核心原则：

• 业务需要时升级（不是技术能力允许就升级）
• 独立演化 = 升级信号
• 团队独立 = 升级信号
• 过早拆分 = 分布式单体

一句话总结：Module = 代码组织，BC = 独立演化，按业务需要升级。