Агрегаты DDD: идентификатор объекта хранения для некорневого объекта в другом агрегате

Рекомендация не хранить ссылку на дочернюю сущность основывается на хороших принципах, но я считаю, что часто вызывает путаницу. На самом деле цель состоит в том, чтобы дочерняя сущность не обязательно имела «глобально уникальный» идентификатор и чтобы ни один репозиторий не предоставлял прямой доступ к дочерней сущности с использованием такого глобально уникального идентификатора.

Однако, если ваш StorageLocation содержит глобальный уникальный идентификатор для Product, а также, возможно, локальный уникальный идентификатор для SKU, тогда нет ничего плохого в таких шаблонах, как:

var storageLocation = _storageLocationRepository.Get(id);
var product = _productRepository.Get(storageLocation.ProductId);
product.DoSomethingToSku(storageLocation.SkuId);

Ключ в том, что, гарантируя, что вы всегда получаете продукт из репозитория, а затем взаимодействуете с дочерней сущностью через продукта, вы гарантируете, что продукт имеет возможность защитить свои собственные инварианты.

Итак, подведем итог:

• Не стесняйтесь сохранять идентификатор дочерней сущности, если вы также сохраняете глобальный идентификатор для ее совокупного корня.
  • В этом случае идентификатор дочерней сущности может быть уникальным локально или глобально - это не имеет значения, если доступ к дочерней сущности осуществляется через совокупный корень.
• Никогда не загружайте дочернюю сущность непосредственно из репозитория и не вызывайте для нее методы - так как тогда у совокупного корня нет возможности защитить свои инварианты.
  • Фактически, у вас никогда не должно быть репозитория для дочерней сущности.

Is holding just an identifier to the Product and Sku in the StorageLocation aggregate acceptable?

Да, поскольку идентификаторы являются объектами значений в DDD, сохранение идентификатора в агрегате StorageLocation не нарушает правила хранения ссылки на дочерний объект другого агрегата, поскольку объект значения является просто объектом значения и больше не имеет прямой связи с исходным совокупный.

I'm aware that a transient reference is deemed allowable, but in this instance (at least as far as I can tell) this information needs to be stored. As mentioned, storing a reference to the Product (or ProductId) is not enough.

Обезвоживание корня агрегата StorageLocation обратно в базу данных должно включать все, что необходимо сохранить. Уровень инфраструктуры определяет, как ваши объекты домена хранятся в физическом репозитории, и может представлять собой совершенно иной дизайн модели, чем ваша модель предметной области, в зависимости от проблем, связанных с технологией сохранения.

Product and Skus have natural identifiers (Part Number, Sku Number). Does this provide greater flexibility for storing these values in the StorageLocation aggregate as they have meaning beyond technical implications.

Нет ничего, с чем можно было бы сравнивать «большую гибкость», потому что вы будете использовать только естественные идентификаторы или временные ссылки для ссылки на сущности внутри агрегата Product из агрегата StorageLocation.

Am I approaching this the wrong way and need to look at things differently. I often find it difficult to break out of a PK / FK mindset.

Имейте в виду, что проблемы уровня сохраняемости не должны связываться с моделью предметной области и что цель состоит в том, чтобы сделать модель предметной области ясной и синонимичной текущим бизнес-правилам.