许多团队在起步阶段纠结于一个老问题：是选微服务换取未来的扩展能力，还是选单体换取当下的部署简单。模块化单体架构之所以值得重新审视，正是因为它拒绝把这两个目标当成互斥选项。它的基本主张可以浓缩为一句话——部署是单体，架构是微服务。
要理解这句话为何成立，需要把"部署形态"与"内部结构"分开看待。传统单体之所以难以扩展，并不是因为它只有一个部署单元，而是因为内部模块之间缺乏清晰边界，代码相互渗透，改一处牵动全身。微服务解决了边界问题，却把边界的代价转嫁到运维上：每个服务都要独立的进程、网络、监控与发布流程，复杂度在系统尚未真正变大时就提前到来。
模块化单体的思路是在同一个部署单元内部，用契约约束模块之间的调用关系。模块对外只暴露约定好的接口，内部实现彼此隔离。这样一来，边界的收益被保留，而跨进程通信、分布式事务、服务发现这些微服务固有的负担则被推迟。企业上线时只需部署一套系统，不必为一堆服务单独规划机器与运维；而当某块业务真正成为瓶颈时，由于边界早已划清，将其拆分为独立服务的改造成本远低于从一团泥球里硬抠。
这种架构对基础能力的复用也更友好。认证、权限、组织架构、审计日志、通知这类几乎每个业务都要用到的能力，可以作为共享的核心模块一次建好，新增业务时按需装配，而不是每开一个系统就重新补一遍。重复投入减少，边际成本随之下降。
它适合谁，又不适合谁
模块化单体不是银弹。它最契合的场景，是业务领域已经相对清晰、团队规模可控、但对未来增长有预期的系统。此时提前拆分微服务往往是过度设计，而放任单体野蛮生长又会在扩展期付出代价。模块化单体恰好落在中间：用结构纪律换取演进余地。
反过来，如果不同模块对伸缩能力、技术栈或发布节奏有截然不同的硬性要求，单一部署单元就会成为约束，此时微服务的拆分收益才真正超过其运维代价。
判断是否采用这种架构，关键不在于技术本身是否先进，而在于能否持续守住模块边界。契约一旦被绕过、模块开始互相直接访问内部实现，所谓的"架构是微服务"便名存实亡，退化回难以维护的大单体只是时间问题。真正的难点从来不是划出边界，而是让团队在日常迭代中始终尊重它。