Идентификаторы совокупности DDD и внешние ключи

Question

Я довольно новичок в DDD. Я видел несколько примеров проектов, которые используют общий AggregateId (с String, содержащий GUID) в качестве ключа для совокупного корня.

Мне было интересно, как обращаться к aggregateRoot от ребенка в отношениях OneToMany.

Скажите, что есть заказ AggregateRoot и OrderLine. Было бы разумно иметь дополнительный сгенерированный (например, последовательность) id, рядом с GUID, поэтому OrderLine может ссылаться на это на уровне базы данных? Или внешний ключ OrderLine для заказа GUID? Имеются ли последствия для производительности?

например.

BaseAggregateRoot:

@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 в частности. Я согласен с Дэном, что отсутствие последовательных идентификаторов GUID не имеет смысла.

Реляционно говоря, для меня нет необходимости и вообще неразумно иметь два идентификатора для одной записи. Я бы посоветовал вам выбрать один. Итак, если вы каким-то образом застреваете с GUID в своем проекте. Посмотрите, можете ли вы использовать их в качестве ключей, последовательно создавая их. Затем вы можете удалить @Id Long id. Если нет, замените @EmbeddedId аннотацией @Column.

Надеется, что это помогает,

Успехов