java - DDD 聚合 ID 和外键

Question

我是 DDD 的新手。我见过许多使用通用 AggregateId(带有包含 GUID 的字符串)作为聚合根键的示例项目。

我想知道如何从 OneToMany 关系中的 child 引用 aggregateRoot。

假设有一个 Order AggregateRoot 和一个 OrderLine。在 GUID 旁边有一个额外生成的(例如序列)id 是否明智，以便 OrderLine 可以在数据库级别引用它？或者是 orderLine 的外键来订购 GUID ？对性能有影响吗？

例如。

基础聚合根:

@MappedSuperclass  
public abstract class BaseAggregateRoot {
    @EmbeddedId
    @AttributeOverrides({
       @AttributeOverride
       (name = "idValue", column = @Column(name = "aggregateId", nullable = false))
    })
    protected AggregateId aggregateId;
    ...

顺序:

@Entity
public class Order extends BaseAggregateRoot{
    // is this ID necessary?
    @Id
    @GeneratedValue(generator = "OrderSequenceGenerator")
    @SequenceGenerator(name = "OrderSequenceGenerator", sequenceName = "ORD_SEQ1", allocationSize = 1)
    @Column(name = "ord_seq")
    private Long id;

    @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY)
    @JoinColumn(name = "aggregateId")  <-- should this point to ID or aggregateId?
    private List<OrderLine> orderLines;

Answer 1

首先，我想澄清一下，DDD 完全是关于域建模的，与如何域持久化无关。它可能保存在数据库中，但也可能保存在文本文件中。从领域建模的角度来看，哪些(以及如何)实体与其他实体相关很重要，但通常与它们在关系数据库中的相关方式无关。也就是说，请询问销售代表。订单行项目如何识别其所属的订单，他会反过来问你有什么问题。

在性能方面，使用 GUID 作为键存在一些风险。随机生成的 GUID 不适用于聚集索引。最好使用顺序生成算法并让数据库为您提供这些 GUID。以下是有关此主题的讨论的链接:

What are the performance improvement of Sequential Guid over standard Guid?

我建议您阅读 this answer尤其。我同意 Dan 的观点，即拥有连续的 GUID 没有捕获要点。

从关系上讲，对我来说，同一条记录有两个标识符似乎是不必要的，而且通常也不明智。我建议你选择一个。因此，如果您以某种方式在项目中遇到 GUID 问题。通过按顺序生成它们，看看是否可以将它们用作键。然后你可以删除你的@Id Long id。如果不是，请将 @EmbeddedId 替换为 @Column 注释。

希望对您有所帮助，

祝你好运