Nun, ich versuche, domänenbasierte Designprinzipien für meine Anwendung anzuwenden, mit einem umfassenden 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 ein Problem, wenn ich ein Domänenmodell mit 10-15 Datenfeldern habe, wie das folgende:
%Vor%Wie Sie sehen, enthält dieses Domänenmodell viele Datenfelder, die alle wichtig sind und nicht entfernt werden können. 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, nicht wahr?
Was kann ich tun, um mit einem Domänenmodell mit vielen Datenfeldern fertig zu werden? 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.
Was Sie verpasst haben, ist das Konzept eines Value Objects. Wertobjekte sind kleine, unveränderliche Objekte mit Bedeutung in der jeweiligen Domäne.
Ich kenne die Besonderheiten Ihrer Domain nicht, aber wenn Sie Ihre Entität Job betrachten, könnte es ein Wertobjekt JobDescription geben, das wie folgt aussieht:
Dies ist C # -Code, aber ich denke, die Idee sollte klar sein, unabhängig von der Sprache, die Sie verwenden.
Die Grundidee ist, Werte so zu gruppieren, dass sie in der jeweiligen Domäne sinnvoll sind . Dies bedeutet natürlich, dass Wertobjekte auch andere Wertobjekte enthalten können.
Sie sollten auch sicherstellen, dass Wertobjekte durch einen Wert anstatt durch einen Verweis verglichen werden, z. durch die 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 Beispielcode, die nicht direkt mit der Frage verbunden sind:
Das Domänenmodell ist das Ganze, eine Entität ist Teil davon. Daher sollte Ihre Basisklasse Entity und nicht DomainModel heißen.
Sie sollten die Felder Ihrer Klasse private erstellen und protected accessors bereitstellen, wenn dies für die Kapselung erforderlich ist.
In Ihrem Job-Domain-Modell-Objekt ist eine Menge los - es scheint eine große Anzahl von Sorgen zu vermischen und (zumindest für mich) eine Reihe von begrenzten Kontexten vorzuschlagen, von denen einige leicht zu erkennen sind ein Beispiel zu geben.
Wenn Sie die Dinge in Betracht ziehen, die mit Ihrem "Job" -Modell interagieren, müssen Sie dann beispielsweise sowohl die Salary-Eigenschaft als auch die Industry-Eigenschaft prüfen oder mutieren?
Ohne die vollständigen Nuancen der Domäne zu kennen, sind die Gehälter, die Sie für die Führung 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 GEBUNDENEN 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 Mitarbeiter 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 usw.
DDD lehrt uns, dass eine einzige, einheitliche Sicht auf die Welt selten ALLE Anliegen richtig behandelt. Bitte erforschen Sie BOUNDED CONTEXTS - Ihre Software wird dadurch viel flexibler und flexibler.
Tags und Links domain-driven-design domain-model rich-domain-model