追缴系统这类项目，让我越来越重视架构的边界感
如果只是看页面数量，追缴系统可能不算我做过最“花哨”的项目，但如果看复杂度，它绝对算得上很考验人的一类业务。
因为这类系统一旦做深，就不只是页面增删改查那么简单了。权限、模块拆分、插件扩展、动态路由、请求链路、不同业务域之间的协作，都会慢慢冒出来。也正是在这个过程中，我越来越能体会到“架构的边界感”有多重要。
复杂项目最怕的，不是功能多，而是彼此缠在一起
项目早期大家通常都很容易冲着业务速度去，一块功能先做出来再说。这个阶段本身没错，问题在于如果后面不及时梳理边界，很多模块就会开始互相渗透。
一个模块顺手依赖另一个模块的状态，一个通用逻辑夹带了业务判断，一个本该放在扩展层的能力直接写进核心流程，短期看都能跑，但一旦项目变大，维护成本就会明显上升。
追缴这类项目就特别容易出现这种情况。
因为业务链路天然复杂，很多人会本能地把各种逻辑堆到一起，想靠“集中处理”来省事。但真正做久了就会发现，省下来的只是当下几天的时间，后面还的代价更大。
我后来越来越看重“核心做减法，扩展做加法”
这也是我对插件化、模块化这些东西越来越有兴趣的原因。
我不是为了“听起来高级”才做这些设计，而是因为它们确实能解决一个现实问题：让核心系统少背不该背的包袱。
像一些权限能力、动态路由、通用组件、特定业务扩展，如果都直接硬塞进主干里，那主系统迟早会越来越重。相反，如果一开始就尽量把核心流程收紧，把扩展入口留清楚，后面不管是新增业务还是替换实现，都会从容很多。
这件事说起来简单，真正做的时候其实挺考验判断力。因为不是所有东西都值得抽成插件，也不是所有模块都要追求绝对独立。关键还是要看复用价值和后续变化的概率。
权限和路由，是最容易暴露边界问题的地方
我这几年做项目，一个很直观的感受是：权限和路由特别像系统结构的“体检报告”。
如果一个系统的权限模型很乱、路由拼接很乱，往往说明它的业务边界本身就没理清。后面做按钮权限、菜单驱动、动态注册、角色隔离时，问题就会一个个暴露出来。
所以我现在做这类项目，会更愿意先把权限标识、菜单层级、模块职责这些底层约束想清楚，再往上搭业务，而不是先把页面跑起来，后面再一点点补。
这种顺序一开始会慢一点，但后面真的能省很多心。
架构感很多时候不是“大设计”，而是知道什么不该混在一起
以前我理解架构，容易想到一些很大的词，比如系统设计、插件生态、模块分层、工程体系。现在我反而觉得，很多架构感其实就藏在非常具体的判断里。
比如：
- 核心能力和业务能力要不要拆开
- 公共逻辑能不能只做一次，不要每个模块复制
- 某个需求到底该改内核，还是走扩展点
- 当前的方便写法，会不会给后续迭代埋雷
这些判断未必会写进 PPT，但它们会直接决定一个项目是越做越顺，还是越做越乱。
追缴系统这类项目，对我最大的锻炼也许就在这里。
它让我越来越意识到，前端做复杂业务，真正重要的不是“能不能把东西堆出来”，而是“能不能让系统在复杂里依然保持边界清楚”。