Próbuje zrozumieć jak powinny być zaprojektowane modele DDD.
Tak jak to wynika z logiki biznesowej, nie ma uniwersalnego sposobu. To co w jednym kontekście będzie agregatem w innym będzie encją albo value objectem.
Co do twojego przykładu, za co odpowiada klasa OrderPosition? Widzę tylko jakieś id i count. To jest jakaś uproszczona wersja czegoś na wzór:
Kopiuj
public class OrderItem
{
public Product Product { get; }
public int Amount { get; }
}
Stworzenie obiektu OrderPosition powinno być dostępne tylko z poziomu obiektu Order.
Może być a nie musi, zależy od wymagań, w jaki sposób pozycje są tworzone i dodawane do zamówienia. Nie znając dokładnych wymagań ja bym pewnie zrobił coś w tym stylu
Kopiuj
public class Order
{
public void AddProduct(Product product, int amount)
{
// jakaś walidacja, np. żeby ten sam produkt nie występował na osobnych pozycjach
// może wyliczenie rabatu dla konkretnego produktu na podstawie jakichś reguł, pobranych wcześniej
var item = OrderItem.Create(product, amount);
items.Add(item);
// może być tu a może być gdzieś indziej, np. wyliczanie może nastąpić po zmianie statusu na 'zamówienie
//zatwierdzone'... znowu zależy
RecalculateTotalValue();
}
}
Także nie ma tu jednego prawidłowego sposobu.