Ich denke, Sie müssen in diesem Fall zwei Arten der Validierung trennen. Domänenvalidierung und Anwendungsvalidierung .
Die Anwendungsüberprüfung ist das, was Sie haben, wenn Sie überprüfen, ob die Befehlseigenschaft 'text' zwischen 20 und 200 Zeichen enthält. Sie validieren dies also mit der GUI und mit einem View-Model-Validator, der auch nach einem POST auf dem Server ausgeführt wird. Gleiches gilt für E-Mails (übrigens hoffe ich, dass Sie feststellen, dass eine E-Mail wie `32.d +" Hello World .42 "@ mindomän.local" laut RFC gültig ist).
Dann haben Sie eine weitere Validierung; Überprüfen Sie, ob der Artikel vorhanden ist. Sie müssen sich die Frage stellen, warum der Artikel nicht vorhanden sein sollte, wenn tatsächlich ein Befehl von der GUI gesendet wird, mit dem ein Kommentar angehängt werden soll. War Ihre GUI schließlich konsistent und Sie haben einen aggregierten Stamm, den Artikel, der physisch aus dem Datenspeicher gelöscht werden kann? In diesem Fall verschieben Sie den Befehl einfach in die Fehlerwarteschlange, da der Befehlshandler den aggregierten Stamm nicht laden kann.
In dem oben genannten Fall hätten Sie eine Infrastruktur, die Giftnachrichten verarbeitet. Sie würden beispielsweise die Nachricht 1-5 Mal wiederholen und sie dann in eine Poision-Warteschlange verschieben, in der Sie die Sammlung von Nachrichten manuell überprüfen und die relevanten Nachrichten erneut versenden könnten. Es ist eine gute Sache zu überwachen.
Jetzt haben wir also Folgendes besprochen:
Was ist mit Befehlen, die nicht mit der Domäne synchron sind? Vielleicht haben Sie eine Regel in Ihrer Domain-Logik, die besagt, dass nach 5 Kommentaren zu einem Artikel nur Kommentare mit weniger als 400 Zeichen zulässig sind, aber ein Typ war mit dem 5. Kommentar zu spät und musste der 6. sein - die GUI hat es nicht verstanden, weil Es stimmte nicht mit der Domäne überein, als er seinen Befehl sendete. In diesem Fall haben Sie einen 'Validierungsfehler' als Teil Ihrer Domänenlogik und würden das entsprechende Fehlerereignis zurückgeben.
Das Ereignis kann in Form einer Nachricht an einen Nachrichtenbroker oder Ihren benutzerdefinierten Dispatcher erfolgen. Wenn die Anwendung monolithisch ist, kann der Webserver synchron sowohl auf ein Erfolgsereignis als auch auf das erwähnte Fehlerereignis warten und die entsprechende Ansicht / den entsprechenden Teil anzeigen.
Oft haben Sie ein benutzerdefiniertes Ereignis, das für viele Befehlstypen einen Fehler bedeutet, und dieses Ereignis abonnieren Sie aus Sicht des Webservers.
In dem System, an dem wir arbeiten, führen wir eine Anfrage-Antwort mit Befehlen / Ereignissen über einen MassTransit + RabbitMQ-Nachrichtenbus + Broker durch, und wir haben ein Ereignis in dieser bestimmten Domäne (teilweise Modellierung eines Workflows), das benannt ist InvalidStateTransitionError. Die meisten Befehle, die versuchen, sich entlang einer Kante im Zustandsdiagramm zu bewegen, können dieses Ereignis verursachen. In unserem Fall modellieren wir die GUI nach einem schließlich konsistenten Paradigma. Daher senden wir den Benutzer an eine Seite mit dem Befehl "Akzeptiert" und lassen die Ansichten des Webservers anschließend passiv über Ereignisabonnements aktualisieren. Es sollte erwähnt werden, dass wir Event-Sourcing auch in den aggregierten Wurzeln durchführen (und dies auch für Sagen tun werden).
Sie sehen also, viele der Validierungen, über die Sie sprechen, sind tatsächlich Validierungen vom Anwendungstyp, keine tatsächliche Domänenlogik. Es ist kein Problem, ein einfaches Domain-Modell zu haben, wenn Ihre Domain einfach ist, Sie aber DDD ausführen. Wenn Sie jedoch mit der Modellierung Ihrer Domain fortfahren, werden Sie feststellen, dass die Domain möglicherweise nicht so einfach ist, wie es sich zunächst herausstellte. In vielen Fällen akzeptiert der aggregierte Stamm / die aggregierte Entität möglicherweise nur einen durch einen Befehl verursachten Methodenaufruf und ändert einen Teil seines Status, ohne eine Validierung durchzuführen - insbesondere, wenn Sie Ihren Befehlen vertrauen, wie Sie es tun würden, wenn Sie sie auf dem Webserver validieren Sie kontrollieren.
Ich kann empfehlen, die beiden Präsentationen zu DDD von der norwegischen Entwicklerkonferenz 2011 und auch Gregs Präsentation auf der Öredev 2010 anzusehen .
Prost, Henke