Part 11｜模块划分并非越细越好，关键在于明确职责边界

在明确要从业务边界开始拆系统之后，我很快遇到了一个新的现实问题：

业务边界清楚了，但模块到底要拆到什么程度？

一开始，我其实很容易走向一个极端：
既然要清晰，那就尽量拆细一点。

但真正把模块往下拆的时候，我开始发现事情没那么简单。

一、问题是从“商品相关模块”开始出现的

在设计商品域时，我一开始很自然地想到：

• 商品（Product）
• 商品分类（Category）
• 商品品牌（Brand）

从概念上看，它们都很“干净”，
拆成三个模块，看起来也非常合理。

于是问题来了：

分类和品牌，到底要不要独立成模块？

二、拆开之后，我发现“职责”开始变得不清楚

当我尝试把「分类模块」「品牌模块」完全独立出来后，很快遇到一些具体问题：

• 商品上下架时，分类是否需要校验？
• 删除一个分类，是否要联动商品？
• 品牌被禁用，对已有商品有什么影响？

这些问题有一个共同点：

最终要为“商品是否可售”这个结果负责的，始终是商品模块。

但如果分类、品牌完全独立成模块，就会出现一种状态：

• 商品模块要等分类模块给结果
• 分类模块又并不知道商品的真实业务情况
• 出问题时，责任在模块之间来回踢

模块是拆开了，但**“谁兜底”反而变模糊了**。

三、我开始意识到：不是每个概念都值得一个模块

这时候我第一次明确意识到一件事：

模块的价值，不在于概念是否独立，而在于是否需要为一类结果负责。

分类和品牌本身很重要，
但它们并不直接对“商品是否能卖”这个结果负责。

如果把它们拆成完全独立的模块：

• 商品模块就不得不依赖它们
• 但它们又无法为最终结果兜底

这是一种非常危险的结构。

四、我的取舍：让“责任回到商品模块”

最终，我做了一个看起来“不那么优雅”的决定：

• 分类、品牌不作为独立业务模块存在
• 它们的生命周期、状态校验，由商品模块统一兜底
• 分类和品牌更像是商品域内部的重要子结构，而不是平级模块

这个决定的核心不是“好不好看”，
而是非常现实的一点：

当商品出问题时，我不希望再去判断“这到底算谁的锅”。

五、这件事让我重新理解了“模块拆分”

从这个点开始，我对模块拆分的判断标准发生了变化。

我不再问：

• 这个东西能不能拆出来？

而是改成问：

• 如果拆出来，它能不能独立对某一类结果负责？
• 出问题时，我是否能明确指向它？

如果答案是否定的，那即便概念再清晰，我也会非常谨慎。

六、模块拆得少一点，系统反而更稳了

在收紧模块拆分之后，系统反而出现了一些正向变化：

• 商品相关逻辑不再分散在多个模块里
• 校验规则集中，修改成本下降
• 出问题时，定位路径非常直接

模块数量少了一些，
但责任路径反而清晰了很多。

写在最后

回头看，我之所以会从“尽量多拆模块”转向“模块要能各自负责”，并不是理念变了。

而是我在真实设计中越来越确定一件事：

模块存在的意义，不是为了让结构看起来更高级，
而是为了在系统运行时，
清楚地知道：这类问题，应该由谁来兜底。

当一个模块无法对任何一类结果负责时，
它往往只是在系统里制造新的不确定性。

而这种不确定性，
才是长期维护里最贵的成本。