在决定从业务边界开始拆系统之后，我很快遇到了一个非常具体的问题。
这个问题不是“模块怎么拆”，
而是：
某些逻辑，到底该不该跨过模块边界？
这个问题如果不先想清楚，
后面的设计会非常难受。
一、这个问题，是在商品和订单之间出现的
在设计商品和订单相关逻辑时，我一开始是犹豫的。
比如：
- 下单时，是否直接操作商品库存
- 商品是否需要感知订单状态
- 订单取消后，库存回滚该由谁负责
这些问题，从功能角度看都说得通。
如果只是为了把流程跑通，
让订单模块“顺手”去操作商品模块，
是最省事的。
但我很快意识到一个风险：
一旦这么做，商品和订单的职责就会开始混在一起。
二、我意识到：这是一个必须先立边界的地方
如果让订单模块：
- 直接修改商品的库存状态
- 直接依赖商品内部结构
那意味着一件事：
订单模块开始对“商品内部实现”负责了。
这在当前阶段可能没问题，
但我很清楚后面会发生什么：
- 库存规则会变
- 商品形态会变
- 下单方式也会变
一旦订单对商品内部有了改动，
后面任何变化，都会牵一发动全身。
三、我给自己立下的第一条“不能越过”的边界
正是在这个地方，我给系统立下了第一条硬边界：
一个模块，只能依赖另一个模块“公开承诺的接口结果”，
不能依赖它的内部过程。
落到这个例子里，就是：
- 订单只关心“库存是否可用”这个结果
- 商品内部如何判断、如何扣减，是商品自己的事
- 订单处理不应预设商品的库存管理方式
这条边界一旦立住，
很多“顺手的实现”就必须被放弃。
四、这条边界让我放弃了不少“省事”的做法
比如：
- 不在订单里直接写库存扣减逻辑
- 不让订单感知商品的内部状态字段
- 不让商品去反向感知订单流程细节
这些做法在短期内，确实会让实现更麻烦一点。
但它换来的是：
- 商品规则调整时，订单不用跟着改
- 订单流程变化时，不会反向调整商品
- 出问题时，责任边界非常清楚
五、为什么我把这条边界看得这么重
回头看，我之所以把它当成第一条不能越过的边界，原因很简单：
这是我第一次在设计阶段，就明确拒绝了“省事实现”。
如果在这个地方妥协，
后面类似的跨边界需求只会越来越多。
而这条边界一旦立住，
后面的设计反而变得轻松了：
- 我知道哪些事情可以谈
- 哪些事情一开始就不该谈
写在最后
我给这套系统划的第一条“不能越过”的边界，
并不是抽象原则，而是一个非常具体的决定：
订单不能依赖商品的内部实现，
商品也不能被订单流程牵着走。
这条边界看起来很普通，
但如果一开始没立住，
后面整个系统都会被它反复拉扯。
也正是从这一刻开始，
我才真正意识到：
系统设计里的边界，往往不是画出来的，
而是在具体场景里，被逼着做出来的。
