Domain Driven Design-Lookup-Tabellen als aggregierter Root

Question

Wir haben eine Web-Anwendung, wo Sie auf zwei Dienste/Funktionen ("Kaufen" und "Mieten") zugreifen können. In einem ersten Schritt müssen Sie eine ProductCategory aus einer DropDownList auswählen. Nicht jede Produktkategorie kann gekauft oder gemietet werden. Wir haben 5 Produktkategorien:

• A: Kauf/Miete
• B: Kauf/Miete
• C: Kauf/Miete
• D: Nur
• E kaufen: Nur Miete

Wie kann ich das auf eine domänenbasierte Art und Weise gestalten? In meiner Meinung nach ist die Kauf/Miete Eigenschaft nicht eine Eigenschaft des Product sondern des Dienstes selbst:

public class Service 
{ 
    public string Name; // Buy or Rent 
    public List<ProductType> AllowedTypes; 
} 

bearbeiten Zweites Beispiel:

Beiden Dienste haben ein paar gemeinsamen Status (zB erstellt oder beendet), aber auch Sonderstatus (zB "Buy-Status-1"). Ist es eine gute Idee, für beide Dienste dieselbe Statusklasse zu verwenden? Oder besser eine Fachklasse pro Dienst BuyStatus/RentStatus.

Answer 1

Ich denke, es hängt davon ab, ob die „kaufen/mieten“ vs „nur kaufen/mieten nur“ Beziehung ist statische oder dynamische.

Wenn die Beziehung statisch ist (einmal für alle), könnte es einfacher sein, diese Informationen direkt auf der ProductCategory zu haben. Je weniger Klassen, desto besser.

Andererseits, wenn die Beziehung dynamisch ist, könnte die Verwaltung eines dynamischen Zustands durch ein anderes Objekt, das für die Aufrechterhaltung dieses Wissens verantwortlich ist, vereinfacht werden (beispielsweise könnte ein Produkt nur für eine gewisse Zeit und dann "kaufen")/Miete "für einige Zeit usw.).

Dies folgt einer oop-Regel, die besagt, dass Eigenschaften nur Werte sind und wenn Eigenschaften komplizierter werden (z. B. sie ändern sich mit der Zeit und Sie müssen allen Änderungen folgen), dann verschieben Sie sie in separate Klassen.