工程骨架：多模块 Maven 与微服务边界怎么切文章目录工程骨架：多模块 Maven 与微服务边界怎么切引言：第一行代码之前，先想清楚边界一、为什么是"多模块单体"起步，而不是直接微服务二、模块划分：11 个模块，一条业务链原则一：按业务域切，不按技术层切原则二：高频流量域与强一致域分开原则三：对外对接域独立成模块边界判定矩阵：哪些边界由业务一致性决定什么场景才值得拆成微服务三、父 POM：版本只出现一次四、统一返回体：全平台就一个返回结构五、模块依赖检查：边界有没有被守住，让 POM 说话六、配置清单与完整启动路径七、单体优先、按需拆分：模块化单体的实证八、多仓库世界的本地联调九、现实对照：一个微服务平台为"关联"付的胶水成本结语：骨架搭好，该接设备了引言：第一行代码之前，先想清楚边界认知篇攒下了领域模型（第 04 篇），但从这篇开始要动真格写工程了。写一个虚拟电厂平台和写普通 CRUD 系统的第一个区别，不是技术栈，而是边界——这个平台要同时跟三类"外部世界"打交道：向下，接成千上万台异构设备（MQTT/CoAP，协议杂、断连多）；向上，接电网官方系统（负荷管理/调度自动化/交易系统，协议硬、时延刚性）；向内，跑核心业务闭环（评估→聚合→调度→结算，强一致性）。这三种流量的特征完全不同：设备接入层高并发长连接、业务服务层重事务重逻辑、对外对接层重协议重安全。如果把它们揉进一个工程，第一波设备风暴就会拖垮结算服务——这是工程上反复交过的学费。所以本篇解决两个问题：工程骨架怎么搭（多模块 Maven），模块边界画在哪（按业务域而非技术层切分）。文末附有已验证可启动的最小骨架，mvn spring-boot:run一条命令拉起。一、为什么是"多模块单体"起步，而不是直接微服务先说一个反直觉的决策：专栏示例工程openvpp-demo采用Maven 多模块 + 单体启动的形态，而不是上来就 Spring Cloud（微服务开发全家桶）。原因有三：教学效率：读者一条命令mvn spring-boot
