Будет ли добавление CustomerId к сущности Order нарушать принципы DDD или проектирования базы данных, направленные на по ⇐ C#

[Anonymous]

Мы создаем систему с использованием доменно-ориентированного проектирования (DDD) на C# (.NET), и у нас есть проблемы с проектированием, связанные с производительностью.
В настоящее время в нашей модели домена Клиент создает OfferDetails, и каждый OfferDetail может содержать несколько предложений. Заказ создается на основе принятого предложения. Проблема возникает, когда мы хотим отклонить заказ из агрегата «Клиент». Вот текущий код для этого:

Код: Выделить всё

public void RejectOrder(Guid orderId, string note)
{
var order = _offerDetails
.Select(offerDetail => offerDetail.Offers.FirstOrDefault(offer => offer.OrderId == orderId)?.Order)
.FirstOrDefault();

if (order == null)
{
throw new KeyNotFoundException("Order for this customer was not found.");
}

order.MarkAsRejected();
}

При этом выполняется обход вложенной структуры _offerDetails → Offers → Order, чтобы найти целевой заказ. По мере роста этой коллекции производительность становится все более серьезной.
Мы рассматриваем потенциальное решение — добавить CustomerId к сущности Order и сохранить его напрямую. Это позволит осуществлять прямой запрос к таблице Order по CustomerId и OrderId, уменьшая необходимость обходов.
Мой вопрос:
Будет ли добавление CustomerId к объекту Order:

• нарушать принципы DDD, в частности границы агрегирования или
  концепцию владения?
• Нарушают какие-либо общие принципы нормализации или проектирования базы данных?
• Является ли оправданным компромиссом для оптимизации производительности в домене
  где этот поиск является частым?

Мне особенно интересно, как другие подходили к подобным агрегатным отношениям и проблемам поиска в DDD, и является ли введение избыточности, такой как CustomerId в Order, действительным и прагматичным шаблоном в таких случаях.
/>РЕДАКТИРОВАНИЕ
Для пояснения: мы используем EF Core и в настоящее время получаем доступ к связанным объектам через модель домена (т. е. Клиент → OfferDetail → Offer → Order) в памяти. Это сделано намеренно и основано на нашей конструкции DDD, где Customer является корневым агрегатом. Проблема с производительностью связана не с объединениями SQL, а с обходом в памяти все более крупных коллекций. Мы рассматриваем возможность денормализации модели данных путем добавления CustomerId к сущности Order, чтобы можно было обойти обход и напрямую запросить Order по CustomerId и OrderId. Мы хотим оценить, нарушает ли это совокупные границы или вводит неприемлемую избыточность в контексте DDD.