从单体到模块化：后端服务拆分的边界判断

一、拆分的动机

服务拆分不是目的，而是为了让不同团队能独立迭代、让系统能按需扩缩容。如果拆分之后部署更复杂、联调成本更高，却没有带来相应的收益，这次拆分就是失败的。

二、边界怎么划

按业务能力划分边界，而不是按技术分层。一个服务应该围绕一个完整的业务闭环，拥有自己的数据与生命周期。跨服务调用尽量通过接口契约，而不是共享数据库。

三、先模块化再服务化

代码层面的模块化能解决大部分耦合问题，成本远低于拆服务。先把边界在代码里划清楚、依赖方向理顺，等模块真的需要独立部署或独立扩容时，再拆成服务。

四、数据一致性

拆分之后，跨服务的事务不再免费。要么用消息驱动实现最终一致，要么通过业务补偿。设计时要明确哪些操作可以异步、哪些必须强一致，避免把分布式事务当成默认选项。

五、运维成本

服务数量增加会带来监控、日志、链路追踪、发布流程的复杂度。拆分前先确认运维体系能支撑，否则问题会被放大。规模不大的团队，宁可少拆几个服务。