六边形架构下Maven子项目拆分及可执行Jar数量咨询

方案选型 #

优先选方案2：按业务+六边形层级拆分，但要通过合理合并细粒度模块避免子模块爆炸。三个方案的具体分析：

• 方案1（按六边形层级聚合所有业务模块）：所有业务的同层代码混放，比如所有业务的领域模型塞进同一个模块，后期业务扩张后边界彻底模糊，维护难度陡增，完全不推荐。
• 方案2（按业务+六边形层级拆分）：这是最贴合六边形架构“业务隔离+层级依赖清晰”设计逻辑的方案。你遇到的上百个子模块问题，核心是拆分粒度太细。可以这么优化：
  • 合并同业务下的细粒度层级：比如把某业务的领域模型、领域服务合并成一个xxx-domain模块，不用拆成xxx-domain-model、xxx-domain-service；把该业务的数据库访问、外部接口适配合并成xxx-adapter模块，只有当某部分适配逻辑需要被多个业务复用时，再单独抽成独立模块。
  • 用Maven聚合模块分组：把所有业务的领域模块放在domains聚合模块下，适配层放在adapters聚合模块下，避免子模块在根目录杂乱无章。
• 方案3（先按业务再聚合六边形层级）：等于把某业务的所有层级代码打包成一个模块，直接破坏了六边形架构的核心——依赖倒置原则，领域层会被迫耦合适配层的实现细节，边界管控完全失效，不推荐。

最终自研Jar数量预估 #

原项目有7-8个自研Jar，对应原来的业务/功能模块。按优化后的方案2拆分后，自研Jar数量会略多于原数量，大概在10-15个左右：

• 每个原业务模块会拆分成2-3个Jar（比如xxx-domain、xxx-adapter，如果对外API需要单独暴露就再加xxx-api）。
• 跨业务的通用核心能力（比如领域工具类、通用适配组件）会抽成1-2个独立Jar。
• 只要避免不必要的细粒度拆分，完全不会出现上百个Jar的情况，只会保留业务间、层级间的核心边界。

内容的提问来源于stack exchange，提问作者Marc Le Bihan