六边形架构中领域与持久化模型分离时的外键引用问题

针对你提出的ReportEntity存储Customer标识的问题，结合六边形架构和限界上下文的设计原则，直接给出两种方案的分析和最优选择：

方案1：存储Customer的业务ID（String类型customerId） #

这是更符合架构设计原则的选择，核心优势如下：

• 对齐领域模型：领域层的Report实体本身就以业务IDcustomerId关联Customer，持久化层直接映射该字段，无需额外转换逻辑，降低领域与持久化层的适配成本。
• 跨限界上下文友好：如果Customer和Report属于不同限界上下文，业务ID是全局唯一的业务标识，跨上下文识别Customer更可靠，不会因数据库内部ID变化（如分库分表、数据迁移）导致关联失效。
• 避免跨上下文耦合：不需要在Report的持久化层查询Customer的数据库ID，严格遵守限界上下文的隔离原则，不会打破各模块的独立性。

落地注意事项 #

给CustomerEntity的customerId字段添加唯一约束，确保业务ID的唯一性：

@Entity(name = "customer")
data class CustomerEntity(
    @Column(unique = true) var customerId: String,
    var name: String,
    @Id @GeneratedValue(strategy = GenerationType.AUTO) var id: Long = -1
)

ReportEntity保持与领域模型一致的字段设计：

@Entity
data class ReportEntity(
    val reportId: String,
    val date: LocalDate,
    val customerId: String,
    @Id @GeneratedValue(strategy = GenerationType.AUTO) var id: Long = -1
)

同时在领域服务层添加校验逻辑：保存Report前，通过Customer领域服务确认对应的Customer存在，用业务规则替代数据库外键约束，符合六边形架构中业务逻辑内聚于领域层的要求。

方案2：存储Customer的数据库ID（Long类型id） #

这种方案存在明显的设计缺陷：

• 耦合数据库实现细节：数据库自增ID是持久化层的内部实现，领域层无需关心，存储该字段会将领域模型与数据库绑定，违反六边形架构的依赖倒置原则。
• 破坏限界上下文隔离：若Customer和Report属于不同限界上下文，Report的持久化层需要访问Customer的数据库表，会导致上下文之间耦合度上升，违背DDD的限界上下文设计初衷。
• 数据迁移风险：后续Customer表分库分表、数据迁移时，自增ID可能重复或变更，导致所有关联的Report记录失效。

结论 #

优先选择存储Customer的业务ID，既符合架构设计原则，又能保证系统的扩展性和隔离性。

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