Clean Architecture与DDD Java项目：共用User表的实体处理方案咨询

绝对不要在多个模块中复制UserEntityJpa，正确的做法是新增一个共享基础设施模块（比如命名为infrastructure-shared或persistence-common，比单纯的Common更贴合Clean Architecture的分层逻辑）来存放这个通用的JPA实体。

为什么不能复制实体？ #

• 违反DRY原则：同一份实体代码维护多份，后续修改User表结构（比如新增字段、调整映射规则）时，需要同步修改所有模块的实体副本，极易出现遗漏，长期来看维护成本会指数级上升。
• 数据一致性风险：如果不同模块的实体定义出现差异（比如字段名拼写错误、映射关系不一致），会导致同一个User表在不同业务模块中被错误解析，引发读写异常，排查难度极高。
• 不符合Clean Architecture分层：JPA实体属于基础设施层的实现细节，业务模块（认证、订单）属于应用/领域层，不该直接持有基础设施层的重复实现，而是应该依赖共享的基础设施组件。

具体实现建议 #

• 共享模块只存放通用的持久化相关内容：比如共享的JPA实体、通用Repository接口、数据库连接的基础配置等，不要混入任何业务逻辑。
• 各个业务模块（认证、订单）通过依赖该共享模块，直接使用UserEntityJpa进行数据库操作，保证实体定义的唯一性和一致性。

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