Spring Boot微服务共享领域模型疑问：股票投资组合API项目架构咨询

你当前架构的核心问题是拆分微服务后没有拆分对应存储资源，导致出现代码重复、服务紧耦合的问题，目前行业内成熟的解决方案分为三类，可根据你的项目规模选择：

• 方案1：抽离公共领域层二方包（最适合个人小项目）
  把两个服务共用的domain类、DB操作基础DAO、常量枚举都抽成独立的公共代码包，Java栈可打包为jar包，JS栈可打包为npm包，Python栈可封装为独立公共模块，两个服务直接依赖这个包即可，完全消除代码重复，开发成本极低，适合个人项目这种迭代快、团队小的场景。仅需注意公共包版本要做好管理，更新时尽量向下兼容即可。

• 方案2：调整服务边界，彻底拆分DB（标准微服务实践）
  原有两个服务共享DB本质是紧耦合，一旦表结构变动两个服务都要同步修改，根本达不到你预期的故障隔离效果。可调整服务边界如下：

  1. 数据采集服务（对接外部API的服务）独占所有原始数据的DB表，对外提供内部查询接口（可选用gRPC或轻量REST接口）给计算服务
  2. 计算服务仅操作自己独占的计算后指标结果表，需要原始数据时调用数据采集服务的内部接口获取，不需要直接操作原始数据表
     调整后两个服务完全独立，没有共用DB资源，domain类也天然分离，完全符合微服务职责拆分原则，也能达到你要的故障隔离效果：数据采集服务故障时，计算服务最多拿不到新数据，仍可正常返回已计算完成的历史指标。

• 方案3：引入事件驱动架构解耦
  数据采集服务拿到新数据后，直接发送MQ消息（可选用RocketMQ、RabbitMQ甚至Redis消息队列），消息体携带全量原始数据字段，计算服务订阅消息后，自己落地一份原始数据副本到自身的DB中。该方案下两个服务的DB完全独立，各自维护自己的domain类，不需要互相调用，可用性更高，数据一致性可通过消息重试机制保障，适合后续计划扩展更多功能的场景。

选型建议 #

如果你的项目流量不大、迭代速度要求高，直接选用方案1即可，投入最少就能解决你当前的代码重复问题，后续服务规模变大后再迁移到方案2或3即可。

内容的提问来源于stack exchange，提问作者Dimo Georgiev