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