[决策] 为何第一版不做微服务

字段	内容
状态	🔵 设计中
类型	[决策] Rejected（当前阶段）
项目	Mini MES V0
证据	模块边界文档 + 后续单体仓库

---

背景

「IoT 服务 + MES 服务 + 网关服务」拆成多仓多进程，在架构图上很好看。

判断

V0 用 模块化单体（Modular Monolith）：一个 Spring Boot 进程内按包/模块划分 Gateway 接入适配、设备域、查询 API；Gateway 采集端可先独立小进程或同仓模块，但不上服务注册、拆库、分布式事务。

暂不做微服务的原因

1. 团队规模 = 1（实验室）；分布式排障成本由一人承担
2. 领域边界尚未被实验打磨，过早拆服务会拆错
3. 部署与联调时间应留给「采得到、看得见」

模块边界（单体内部先画清）

device      设备档案 / 在线
ingest      接收 Gateway HTTP
query       监控查询 API
（未来）workorder  工单——仍可先同进程

真要拆服务时，应按已被流量验证的边界拆，而不是按名词拆。

重新评估触发

• 独立扩展/发布节奏明确不同
• 或 IoT 写入与 MES 事务隔离有强诉求且单体已被证伪

结论

第一版不做微服务；做清晰模块。 面试时可讲清「为什么不拆」，比「我用了微服务」更有说服力。