当我真正进入系统设计阶段时，有一个问题很快摆在了我面前：
这套系统，第一刀该从哪里下？
是先定技术架构，
还是先画模块图，
又或者直接从某个功能最复杂的地方开始拆？
我最后选择的，并不是这些。
一、我很快排除了“从技术结构开始”
一开始，我也认真考虑过从技术角度入手：
- 先定分层
- 再定模块
- 最后往里填业务
这条路并不陌生，资料也很多，看起来也很“正规”。
但我很快意识到一个问题：
如果一开始就按技术结构拆，
后面所有业务，都会被迫去适应这套结构。
而我之前在二次开发里遇到的很多麻烦，
恰恰就是这么来的。
二、我真正困扰的，从来不是“代码怎么放”
回过头看，我在前面几篇里反复提到的困扰，其实有一个共同点：
- 改功能时，不知道该改哪
- 加需求时，很难判断归属
- 出问题时，责任边界不清楚
这些问题，几乎都不是“技术实现”的问题。
它们更像是在问：
这件事，到底是谁的职责？
而这个问题，技术结构是回答不了的。
三、业务边界，才是我真正需要先想清楚的东西
在意识到这一点之后，我开始把注意力从“怎么实现”，
转向了一个更基础的问题：
这套系统里，有哪些相对独立、长期存在的业务？
不是功能列表，
也不是页面清单，
而是那种即使技术换了、实现重写了，也依然存在的东西。
例如：
- 用户管理职责
- 商品管理职责
- 订单处理职责
- 商户运营职责
这些东西，并不会因为你换了框架就消失。
四、从业务边界开始，很多纠结会自动消失
当我开始用“业务边界”来思考系统拆分时，
一些之前反复纠结的问题，反而变简单了。
比如：
- 这个需求是商品的问题，还是订单的问题
- 这个逻辑该不该放在用户模块里
- 这个改动会不会越过别的模块边界
一旦边界被明确，
很多争论其实就没有必要继续了。
不是因为答案绝对正确，
而是因为判断标准变清楚了。
五、业务边界，比“模块数量”更重要
在这个过程中，我刻意避免一件事：
为了“看起来清晰”，过早地把模块拆得很细。
因为我发现，如果业务边界本身还没想清楚，
模块拆得再细，也只是把问题换了一种形式保存下来。
还是要优先明确：
- 哪些职责必须分离
- 可暂时合并的职责
- 后期难以拆分的关键边界
模块数量，反而是后面的事情。
六、从业务边界开始，也让我更容易“拒绝需求”
还有一个很现实的变化是：
当边界清楚之后，我在面对需求时更容易做判断了。
因为我可以很明确地问自己：
- 这个需求，是不是越过了系统当前的业务边界
- 如果支持它，会不会破坏原本的责任划分
- 这是不是在逼系统去承担它不该承担的事情
很多需求，并不是“做不做得出来”的问题，
而是“该不该让系统负责”的问题。
七、这是一个为“长期演进”做准备的选择
我选择从业务边界开始拆系统，还有一个很现实的原因：
我知道这套系统不会一次成型。
它会被不断修改、不断补充、不断调整。
在这种前提下，我更希望：
- 修改是在边界内发生
- 扩展是沿着边界增加
- 推翻是局部的，而不是整体的
业务边界，恰恰是支撑这种演进方式的基础。
写在最后
回头看，我之所以选择从「业务边界」开始拆系统，
并不是因为这是某种“最佳实践”。
而是因为在经历了足够多混乱之后，
我越来越确定一件事：
如果一开始没想清楚谁该负责什么，
后面不管用什么技术，都会很痛苦。
从业务边界下第一刀，
不是为了拆得多漂亮，
而是为了给后面的所有设计，
一个不容易失控的起点。
