后端架构的复杂度本质上只有两个来源：业务复杂度和技术复杂度。业务复杂度是领域本身的固有属性——一个交易系统天然比一个博客系统复杂，这是无法消除的。技术复杂度则是我们为了解决业务问题而引入的额外负担——分布式事务、缓存一致性、服务间通信。
很多架构问题的根源在于混淆了这两者。当团队把业务逻辑散落在各种技术组件中时，业务复杂度和技术复杂度就纠缠在一起，形成了一团无法维护的”大泥球”。DDD 的核心价值不在于那些战术模式，而在于它提供了一种将业务复杂度和技术复杂度分离的思维方式。
“什么时候该拆微服务”大概是后端架构中被问得最多的问题。我的经验是：如果你不确定是否应该拆，那就不要拆。微服务带来的运维成本远比大多数人想象的高——服务发现、链路追踪、分布式事务、接口版本管理，每一项都是实实在在的工程投入。
更好的策略是”模块化单体”——在单体应用内部保持清晰的模块边界，让未来的拆分成为一个低风险的重构操作，而不是一次高风险的架构迁移。当某个模块的团队规模、发布频率或扩缩容需求明显不同于其他模块时，才是拆分的合理时机。
技术债这个概念之所以有效，是因为它用了”债务”这个财务隐喻——债务不是不能借，关键是要知道利率多高、什么时候还。但在实践中，大多数团队对技术债的管理停留在”我们知道有技术债”的阶段，缺乏量化和优先级排序的手段。
我们尝试过一种简单的量化方法：为每项技术债标注”触发频率”和”每次影响时间”。比如某个缓存设计不合理，每周导致 2 次手动介入，每次耗费 1 小时——这就是每周 2 小时的”利息”。当这个利息累计超过”还债”的成本时，重构的优先级自然就上来了。