Domen Driven Architektur und Benutzer Tippfehler/Fehler

Question

DDD lehrt uns, unsere Klassen wie ihre realen Prototypen zu bauen.

So anstelle von Setzern

job = new Job 
job.person = person 
job.since = time.Now() 
job.title = title 

definieren wir gut genannten Methoden in unserer Aggregations Wurzel

job = person.promote(title, /** since=time.Now() **/) 

Jetzt kommt der schwierige Teil

Angenommen wir eine Benutzeroberfläche für ein HR, wo er/sie gibt ein neues title über das HTML-Formular ein und macht einen Tippfehler wie "Programmierer" (Natürlich würde es in der realen Anwendung eine Auswahlliste geben, aber hier haben wir eine Texteingabe), oder wählt ein falsches Datum (wie Standard heute)

Jetzt haben wir ein Problem. Es gibt keine Tippfehler in der realen Welt. Unser John Doe ist definitiv ein "Programmierer" und nie ein "Programmer"

Wie beheben wir diesen Tippfehler in unserem Domain-Modell?

Unsere Person hat nur promote, demote, fire usw. Methoden, die die HR-Domänenmodell widerspiegeln.

Wir konnten ein wenig betrug und die Job Aufzeichnung direkt ändern, aber jetzt haben wir eine Job.setTitle Methode, die nicht unser Domänenmodell widerspiegelt und ist auch Setter böse, wissen Sie.

, die ein wenig „akademisch“ aussehen, aber das ist wirklich nervt mich, wenn ich versuche

Answer 1

Eine andere Seite von DDD einen guten Domain-Modell für eine komplexe Anwendung zu erstellen ist Invarianten - „always valid“ Einheit. Und wenn Sie versuchen, diese Invariante zu brechen (eine Regel), müssen Sie die Ausführung stoppen und "laut" sagen (Ausnahme auslösen). Sie müssen also eine Liste gültiger Titel haben, und wenn Sie versuchen, den Titel (egal wie) in den ungültigen Status zu ändern, müssen Sie eine sinnvolle Ausnahme auslösen.

Um Tippfehler zu beheben, müssen Sie Operationen in Ihrer Domäne trennen promote ist eine Operation (es kann etwas überprüfen, contratulation E-Mail gesendet :) und so weiter). Und edit Operation - nur um einige Eigenschaften zu bearbeiten. Der Unterschied liegt also in der Logik der Operationen. Sie können promote nicht ohne einige Vorbedingungen aufrufen (z. B. erforderliche Erfahrung des Arbeiters), aber Sie können edit aufrufen und den Namen des Arbeiters wegen Typ korrigieren. Und in der Regel sind diese Operationen zwischen verschiedenen Benutzern getrennt: nur HRs können promote aber ein Arbeiter edit seinen Namen, wenn es falsch ist. Diese Lösung ist sehr kompliziert für ein solches Beispiel, aber es ist immer mit DDD. Das Hauptkonzept - getrennte Operationen. Jeder mit seinen eigenen Bedingungen, Berechtigungen, Regeln.

A question über Invarianten (Regeln).

Answer 2

Wenn ein Client Daten reingibt, ist die zugrunde liegende Domäne in diesem (beschränkten) Kontext nicht sehr tief. In diesen Fällen ist es in Ordnung, eine Anwendung im CRUD-Stil zu verwenden und Titel zu ändern (setTitle()).

Stellen Sie sicher, dass abhängige BCs (z. B. Abrechnung, Urlaubsplanung, ...)) Wenn keine "ungültigen Daten" vorhanden sind, können Sie auf Änderungen in Ihrem CRUD-Kontext entsprechend reagieren.

Answer 3

Die Anwendung sollte Eingang Korrektheit erzwingen, bevor es die Domänenschicht erreicht hat, keinen Müll Eingang. Wenn das bedeutet, ein Dropdown für die Berufsbezeichnungen zu verwenden, dann sei es so. Sie können den Titel anhand vorhandener Titel validieren.

In meiner Firma von 18000 Mitarbeitern geschieht Typo die ganze Zeit. Sie müssen pragmatisch sein und akzeptieren, dass es in Ihrem Code (in der einen oder anderen Weise) Setter geben wird.

Pragmatisches Denken ist sehr viel im Kern des domänengetriebenen Designs, und es macht Dinge einfach .

„Reinheit ist in der Theorie gut, aber zu erreichen in der Praxis kann es sehr schwierig sein, und manchmal müssen Sie den pragmatischen Ansatz wählen“ - Muster, Prinzipien und Praktiken des Domain-Driven Design (2015)

Answer 4

"Es gibt keine Tippfehler in der realen Welt", ich verstehe, was Sie meinen, aber das ist nicht wahr, es gibt menschliche Fehler in realen Szenarien und sie sollten in Ihrer Domäne berücksichtigt werden, wenn sie häufig sind.

Wenn Dateneingabefehler nicht häufig sind, kann es nicht die zusätzliche Modellierung Anstrengungen wert sein und diejenigen, könnten vielleicht nur direkt in der DB repariert. Es hängt auch davon ab, ob das Unternehmen etwas über diese Fehler lernen möchte oder nicht. Wenn jedoch Dateneingabefehler häufig auftreten, kann dies ein Hinweis darauf sein, dass das System möglicherweise nicht genügend Anleitungen bietet, und das Unternehmen möchte möglicherweise mehr über diese Fehler erfahren, um Prozesse effizienter und weniger fehleranfällig zu machen .

können Sie möchten eine Operation wie job.correctTitle(...), vielleicht in einem BC Datenkorrektur gewidmet implementieren? Außerdem ist es sehr selten, dass jede einzelne Information fehlerhaft ist, so dass korrigierende Operationen getrennt werden können. Das bedeutet, dass Sie wahrscheinlich keine job.correctAllInformation(...) Art von Operation benötigen.

Dieses ganze Szenario ist sehr fiktiv, da Jobtitel normalerweise in einem separaten BC verwaltet werden, wo sie verwendet werden, und sie würden wahrscheinlich aus einer Liste ausgewählt werden, daher würden Tippfehler weniger häufig sein, aber Sie werden immer handeln müssen mit Dateneingabefehlern. Die Auswahl der geeigneten Lösung ist nicht immer einfach und wird von Fall zu Fall variieren, aber versuchen Sie, pragmatisch zu bleiben und streben Sie nicht nach dem perfekten Modell in jeder Sphäre Ihrer Domäne.