"小单体微服务"陷阱：只做物理拆分，没有逻辑边界，最终变成分布式大泥球

一些项目团队把单体拆成微服务时，走的不是”先建领域模型”这条路，而是简单地按业务功能把原来的单体软件包物理拆分成多个所谓”微服务”包，但每个包内部依然是传统三层架构、代码高度耦合、逻辑边界不清晰——书中把这种东西称为”小单体微服务”。这类小单体微服务在项目初期看起来边界清晰，但随着新需求不断加入，每一个小单体都会持续膨胀；等某天真的需要把某部分业务功能从中拆出去、或者和其他微服务重组时，才发现这个曾经”边界清晰”的小单体，早已变成了一个代码高度耦合、边界模糊的”臃肿大单体”，团队不得不重复经历一轮又一轮”从大单体再拆成小单体”的返工。问题的根源在于这类拆分只定义了一个维度的边界——微服务之间的物理边界，给系统披上了一层分布式架构的外衣，但骨子里依然是单体架构的设计思维，完全没有定义微服务内部真正重要的逻辑边界和代码边界。这个案例给出一条重要警示：给系统做”物理拆分”（拆成多个独立部署单元）本身不等于解决了架构问题，如果拆分之前没有先想清楚业务领域内在的逻辑边界该划在哪里，物理拆分只是把原来单体内部混乱的耦合，原封不动地搬进了一堆新的、看似独立的服务里，本质问题一点没解决，还多了分布式系统的额外复杂度。