Zeige Daten auf der Benutzeroberfläche in der Hexagonal-Architektur

Question

Ich lerne DDD und Hexagonal Architektur, ich denke, ich habe die Grundlagen. Aber ich bin mir nicht sicher, wie ich das lösen soll: Wie zeige ich dem Benutzer Daten an?

So, zum Beispiel, ich habe eine einfache Domäne mit einer Worker-Entität mit einigen Funktionen (einige Methoden verursachen die Entität zu ändern) und ein WorkerRepository, so dass ich Arbeiter beibehalten kann. Ich habe eine Anwendungsebene mit einigen Befehlen und Befehlsbus, um die Domäne zu manipulieren (wie Workers zu erstellen und ihre Arbeitsstunden zu aktualisieren, die Änderungen persistent zu halten) und eine Infrastrukturschicht, die die Implementierung des WorkerRepository und einer GUI-Anwendung hat.

In dieser Anwendung möchte ich alle Arbeiter mit einigen ihrer Daten zeigen, und sie zu ändern. Wie zeige ich die Daten an?

1. Ich könnte es einen Verweis auf die Implementierung von WorkerRepository geben. Ich denke, es ist keine gute Lösung, weil ich auf diese Weise neue Workers in das Repository einfügen und den Befehlsbus überspringen kann. Ich möchte, dass alle Änderungen über den Befehlsbus laufen.
2. Okay, dann würde ich das WorkerRepository in WorkerQueryRepository und WorkerCommandRepository (nach CQRS) aufteilen, und verweisen nur auf das WorkerQueryRepository. Es ist immer noch keine gute Lösung, weil das Repo Arbeitsteilen zurückgibt, die über Methoden verfügen, die sie ändern, und wie werden diese Änderungen beibehalten?
3. Sollte ich zwei Arten von Repositories erstellen? Einer würde in der Domänen- und Anwendungsschicht verwendet werden und der andere würde nur zum Bereitstellen von Daten für die Außenwelt verwendet werden. Die zweite würde keine vollwertigen Worker-Entitäten zurückgeben, sondern nur WorkerDTOs, die nur die Daten enthalten, die die GUI benötigt. Auf diese Weise hat die GUI keine andere Möglichkeit, Workers zu ändern, nur über den Befehlsbus.

Ist der dritte Ansatz der richtige Weg? Oder irre ich mich, dass die Änderungen durch den Befehlsbus gehen müssen?

Answer 1

Sollte ich zwei Arten von Repositories erstellen? Einer würde in der Domänen- und Anwendungsschicht verwendet werden und der andere würde nur zum Bereitstellen von Daten für die Außenwelt verwendet werden. Die zweite würde keine vollwertigen Worker-Entitäten zurückgeben, sondern nur WorkerDTOs, die nur die Daten enthalten, die die GUI benötigt.

Das ist der CQRS-Ansatz; es funktioniert ziemlich gut.

Greg Young (2010)

CQRS ist einfach die Schaffung zweier Objekte, bei denen es ein bisher nur war. Die Trennung erfolgt basierend darauf, ob die Methoden ein Befehl oder eine Abfrage sind (dieselbe Definition, die von Meyer in der Befehls- und Abfragetrennung verwendet wird, ein Befehl ist eine beliebige Methode, die den Status ändert und eine Abfrage ist eine Methode, die einen Wert zurückgibt).

Die aktuelle Bezeichnung für die WorkerDTO, die Sie vorschlagen, ist "Projection". Du wirst oft mehrere haben. das heißt, Sie können eine separate Projektion für jede Ansicht eines Arbeiters in der GUI haben. (Das hat den netten Nebeneffekt, dass die Ansicht einfacher wird - es muss nicht über die Daten nachgedacht werden, die es enthält, weil die Daten bereits sinnvoll formatiert sind).

Eine andere Art zu denken, ist, dass Sie eine "schreibgeschützte" Darstellung (das Aggregat) und "schreibgeschützte" Darstellungen (die Projektionen) haben.In beiden Fällen lesen Sie den aktuellen Status aus dem Buch des Datensatzes (über das Repository) und verwenden dann diesen Status, um die gewünschte Darstellung zu erstellen.

Da die gelesenen Modelle nicht gespeichert werden müssen, sind Sie wahrscheinlich besser dran denken Fabrik, anstatt Repository, auf der Leseseite. (Im Jahr 2009 verwendete Greg Young aus demselben Grund "Provider".)

Sobald Sie den ersten Schritt zum Trennen der beiden Objekte ausgeführt haben, können Sie ihre verschiedenen Anwendungsfälle unabhängig voneinander behandeln.

Wenn Sie z. B. die Leseleistung skalieren müssen, können Sie das Buch des Datensatzes auf mehrere Slave-Kopien replizieren und Ihre Projektionsfactory von den Slaves anstelle des Masters laden. Oder um zu untersuchen, ob ein anderer Persistenzspeicher (Schlüsselwertspeicher, Graphdatenbank, Volltext-Indexer) geeigneter ist. Udi Dahan rezensiert eine Reihe dieser Ideen in CQRS - but different (2015).