Part 10｜我给这套系统划的第一个边界

在决定从业务边界开始拆系统之后，我很快遇到了一个非常具体的问题。

这个问题不是“模块怎么拆”，
而是：

某些逻辑，到底该不该跨过模块边界？

这个问题如果不先想清楚，
后面的设计会非常难受。

一、这个问题，是在商品和订单之间出现的

在设计商品和订单相关逻辑时，我一开始是犹豫的。

比如：

• 下单时，是否直接操作商品库存
• 商品是否需要感知订单状态
• 订单取消后，库存回滚该由谁负责

这些问题，从功能角度看都说得通。

如果只是为了把流程跑通，
让订单模块“顺手”去操作商品模块，
是最省事的。

但我很快意识到一个风险：

一旦这么做，商品和订单的职责就会开始混在一起。

二、我意识到：这是一个必须先立边界的地方

如果让订单模块：

• 直接修改商品的库存状态
• 直接依赖商品内部结构

那意味着一件事：

订单模块开始对“商品内部实现”负责了。

这在当前阶段可能没问题，
但我很清楚后面会发生什么：

• 库存规则会变
• 商品形态会变
• 下单方式也会变

一旦订单对商品内部有了改动，
后面任何变化，都会牵一发动全身。

三、我给自己立下的第一条“不能越过”的边界

正是在这个地方，我给系统立下了第一条硬边界：

一个模块，只能依赖另一个模块“公开承诺的接口结果”，
不能依赖它的内部过程。

落到这个例子里，就是：

• 订单只关心“库存是否可用”这个结果
• 商品内部如何判断、如何扣减，是商品自己的事
• 订单处理不应预设商品的库存管理方式

这条边界一旦立住，
很多“顺手的实现”就必须被放弃。

四、这条边界让我放弃了不少“省事”的做法

比如：

• 不在订单里直接写库存扣减逻辑
• 不让订单感知商品的内部状态字段
• 不让商品去反向感知订单流程细节

这些做法在短期内，确实会让实现更麻烦一点。

但它换来的是：

• 商品规则调整时，订单不用跟着改
• 订单流程变化时，不会反向调整商品
• 出问题时，责任边界非常清楚

五、为什么我把这条边界看得这么重

回头看，我之所以把它当成第一条不能越过的边界，原因很简单：

这是我第一次在设计阶段，就明确拒绝了“省事实现”。

如果在这个地方妥协，
后面类似的跨边界需求只会越来越多。

而这条边界一旦立住，
后面的设计反而变得轻松了：

• 我知道哪些事情可以谈
• 哪些事情一开始就不该谈

写在最后

我给这套系统划的第一条“不能越过”的边界，
并不是抽象原则，而是一个非常具体的决定：

订单不能依赖商品的内部实现，
商品也不能被订单流程牵着走。

这条边界看起来很普通，
但如果一开始没立住，
后面整个系统都会被它反复拉扯。

也正是从这一刻开始，
我才真正意识到：
系统设计里的边界，往往不是画出来的，
而是在具体场景里，被逼着做出来的。