Part 09｜我为什么选择从「业务边界」开始拆系统

当我真正进入系统设计阶段时，有一个问题很快摆在了我面前：

这套系统，第一刀该从哪里下？

是先定技术架构，
还是先画模块图，
又或者直接从某个功能最复杂的地方开始拆？

我最后选择的，并不是这些。

一、我很快排除了“从技术结构开始”

一开始，我也认真考虑过从技术角度入手：

• 先定分层
• 再定模块
• 最后往里填业务

这条路并不陌生，资料也很多，看起来也很“正规”。

但我很快意识到一个问题：

如果一开始就按技术结构拆，
后面所有业务，都会被迫去适应这套结构。

而我之前在二次开发里遇到的很多麻烦，
恰恰就是这么来的。

二、我真正困扰的，从来不是“代码怎么放”

回过头看，我在前面几篇里反复提到的困扰，其实有一个共同点：

• 改功能时，不知道该改哪
• 加需求时，很难判断归属
• 出问题时，责任边界不清楚

这些问题，几乎都不是“技术实现”的问题。

它们更像是在问：

这件事，到底是谁的职责？

而这个问题，技术结构是回答不了的。

三、业务边界，才是我真正需要先想清楚的东西

在意识到这一点之后，我开始把注意力从“怎么实现”，
转向了一个更基础的问题：

这套系统里，有哪些相对独立、长期存在的业务？

不是功能列表，
也不是页面清单，
而是那种即使技术换了、实现重写了，也依然存在的东西。

例如：

• 用户管理职责
• 商品管理职责
• 订单处理职责
• 商户运营职责

这些东西，并不会因为你换了框架就消失。

四、从业务边界开始，很多纠结会自动消失

当我开始用“业务边界”来思考系统拆分时，
一些之前反复纠结的问题，反而变简单了。

比如：

• 这个需求是商品的问题，还是订单的问题
• 这个逻辑该不该放在用户模块里
• 这个改动会不会越过别的模块边界

一旦边界被明确，
很多争论其实就没有必要继续了。

不是因为答案绝对正确，
而是因为判断标准变清楚了。

五、业务边界，比“模块数量”更重要

在这个过程中，我刻意避免一件事：

为了“看起来清晰”，过早地把模块拆得很细。

因为我发现，如果业务边界本身还没想清楚，
模块拆得再细，也只是把问题换了一种形式保存下来。

还是要优先明确：

• 哪些职责必须分离
• 可暂时合并的职责
• 后期难以拆分的关键边界

模块数量，反而是后面的事情。

六、从业务边界开始，也让我更容易“拒绝需求”

还有一个很现实的变化是：

当边界清楚之后，我在面对需求时更容易做判断了。

因为我可以很明确地问自己：

• 这个需求，是不是越过了系统当前的业务边界
• 如果支持它，会不会破坏原本的责任划分
• 这是不是在逼系统去承担它不该承担的事情

很多需求，并不是“做不做得出来”的问题，
而是“该不该让系统负责”的问题。

七、这是一个为“长期演进”做准备的选择

我选择从业务边界开始拆系统，还有一个很现实的原因：

我知道这套系统不会一次成型。

它会被不断修改、不断补充、不断调整。

在这种前提下，我更希望：

• 修改是在边界内发生
• 扩展是沿着边界增加
• 推翻是局部的，而不是整体的

业务边界，恰恰是支撑这种演进方式的基础。

写在最后

回头看，我之所以选择从「业务边界」开始拆系统，
并不是因为这是某种“最佳实践”。

而是因为在经历了足够多混乱之后，
我越来越确定一件事：

如果一开始没想清楚谁该负责什么，
后面不管用什么技术，都会很痛苦。

从业务边界下第一刀，
不是为了拆得多漂亮，
而是为了给后面的所有设计，
一个不容易失控的起点。