Domain Driven Design: Wie geht man mit komplexen Modellen mit vielen Datenfeldern um?

Question

Nun, ich versuche, Domain-driven Design-Prinzipien für meine Anwendung zu verwenden, mit einem reichen Domänenmodell, das sowohl Datenfelder als auch Geschäftslogik enthält. Ich habe viele DDD-Bücher gelesen, aber es scheint, dass ihre Domain-Modelle (genannt Entitäten) sehr einfach sind. Es wird zu einem Problem, wenn ich einen Domain-Modell mit 10 bis 15 Datenfelder haben, wie die folgende Liste:

class Job extends DomainModel{ 

    protected int id; 
    protected User employer; 
    protected string position; 
    protected string industry; 
    protected string requirements;  
    protected string responsibilities;  
    protected string benefits; 
    protected int vacancy; 
    protected Money salary; 
    protected DateTime datePosted; 
    protected DateTime dateStarting; 
    protected Interval duration; 
    protected String status; 
    protected float rating; 

    //business logic below 
} 

Wie Sie das Domain-Modell zu sehen, eine Menge von Datenfeldern enthält, und alle von ihnen sind wichtig und kann nicht entfernt werden. Ich weiß, dass ein gutes Rich-Domain-Modell keine Setter-Methoden enthalten sollte, sondern seine Daten an den Konstruktor übergeben und die Status mithilfe der Geschäftslogik mutieren sollte. Für das obige Domänenmodell kann ich jedoch nicht alles an den Konstruktor übergeben, da dies zu mehr als 15 Parametern in der Konstruktormethode führt. Eine Methode sollte nicht mehr als 6-7 Parameter enthalten, denkst du nicht?

Was kann ich tun, um mit einem Domänenmodell mit vielen Datenfeldern umzugehen? Soll ich es zerlegen? Wenn das so ist, wie? Oder vielleicht sollte ich einfach eine Builder-Klasse oder eine Reflektion verwenden, um ihre Eigenschaften bei der Instanziierung zu initialisieren, damit ich den Konstruktor nicht mit so vielen Argumenten belaste? Kann jemand einen Rat geben? Vielen Dank.

Answer 1

Was Sie verpasst haben, ist das Konzept eines Value Object. Wertobjekte sind kleine, unveränderliche Objekte mit Bedeutung in der jeweiligen Domäne.

ich weiß nicht, die Besonderheiten Ihrer Domäne, aber an Ihrer Job Einheit suchen, könnte es ein Wertobjekt JobDescription sein, der wie folgt aussieht:

class JobDescription { 
    public JobDescription(string position, string requirements, string responsibilities) { 
     Position = position; 
     Requirements = requirements; 
     Responsibilities = responsibilities; 
    } 

    public string Position {get;} 
    public string Requirements {get;} 
    public string Responsibilities {get;} 
} 

Dies ist C# -Code, aber ich denke, Die Idee sollte klar sein, unabhängig von der Sprache, die Sie verwenden.

Die Grundidee ist Gruppenwerte in einer Weise, die in der jeweiligen Domäne Sinn macht. Dies bedeutet natürlich, dass Wertobjekte auch andere Wertobjekte enthalten können.

Sie sollten auch sicherstellen, dass Wertobjekte durch Wert anstelle von Referenz verglichen werden, z. durch Implementierung von IEquatable<T> in C#.

Wenn Sie Ihren Code mit diesem Ansatz umgestalten, erhalten Sie weniger Felder für Ihre Entität, sodass die Verwendung der Konstruktorinjektion (die dringend empfohlen wird) wieder möglich wird.

---

Weitere Hinweise zu Ihrem Beispiel-Code, der nicht direkt mit der Frage verbunden sind:

• Das Domänenmodell ist das Ganze, eine Einheit ist ein Teil davon. Daher sollte Ihre Basisklasse Entity heißen und nicht DomainModel.

• Sie sollten die Felder Ihrer Klasse private erstellen und protected Accessoren zur Verfügung stellen, wo erforderlich, um die Kapselung aufrechtzuerhalten.

Answer 2

Es ist eine Menge in Ihrem Job Domain-Modell Objekt los - es scheint, eine große Anzahl von Bedenken zu mischen, und (für mich zumindest) eine Reihe von begrenzten Kontexten schlägt vor, von denen einige sind leicht zu erkennen, um ein Beispiel zu geben.

1. Vergütung (pay, Leistungen)
2. Organisationsposition (Berichtslinie)
3. Person spec (Fähigkeiten)
4. Job-Spezifikation (Aufgaben)
5. usw.

Sie Wann Berücksichtigen Sie die Dinge, die mit Ihrem "Job" -Modell interagieren, ob Sie beispielsweise die Salary-Eigenschaft und die Industry-Eigenschaft prüfen oder mutieren müssen ple?

Ohne die vollständigen Nuancen der Domäne zu kennen, sind die Gehälter, die Sie für das Halten einer Position erhalten, und die Branche, in der Sie arbeiten, nicht wirklich miteinander verbunden, oder? Nicht ein rhetorischer Punkt; Das sind die Fragen, die Sie den Domain-Experten stellen müssen.

Wenn sie KEINE Interaktion haben, dann haben Sie festgestellt, dass diese beiden Dinge in zwei verschiedenen BEGRENZTEN KONTEXTEN existieren. Die Gehaltsseite braucht keine Interaktion mit der Industrie Seite und umgekehrt, und selbst wenn sie tat, müssen sie als Staat in demselben Prozess zur gleichen Zeit gehalten werden?

Denken Sie über den Lebenszyklus nach, wie eine Person ein Angestellter wird; eine Person bewirbt sich um einen Job. Der Job hat eine Spezifikation, Gehaltsspanne. Die Person nimmt an einem Interview teil. Die Vermieter bieten der Person die Position an. Die Person akzeptiert. Die Person ist jetzt ein Angestellter, kein Kandidat mehr. Der neue Mitarbeiter sammelt nun Urlaub und Sozialleistungen und hat ein Startdatum etc.

DDD lehrt uns, dass eine einzige, einheitliche Sicht der Welt selten alle Bedenken korrekt erfüllt. Erkunden Sie BOUNDED CONTEXTS - Ihre Software wird dadurch viel flexibler und flexibler.