DDD NoSQL Storage und Domain-Modell vs View-Modell

Question

Ich versuche, DDD-Muster zu verwenden und als persistenter Speicher erwäge ich die Verwendung einer NoSQL-Datenbank wie LiteDB, RavenDB oder DocumentDB.

Einer meiner Vorteile gegenüber relationalen DB wäre, dass meine Domänenmodelle (ganze Aggregate) als JSON-Dokument serialisiert und in einer DB gespeichert werden könnten, ohne Domänenmodell zu Datenmodellzuordnung zu verwenden.

Aber was ist mit dem Lesen der Daten für den Zweck der Anzeige auf dem Bildschirm. Meine Benutzeroberfläche zeigt Ansichten basierend auf Ansichtsmodellen an, aber wie werden sie erstellt? Abfrage ich den Dokument-DB über. mein Domain-Modell und dann ordnen Sie es zu Modell anzeigen?

Ich frage dies, weil es in der Regel erwähnt "Verwenden Sie nicht Ihr Domain-Modell für Abfragen (Modell lesen)". Vermeidung von Domänenmodell zu Datenmodell Mapping

Answer 1

Einer der Vorteile für mich, über relationale DB, würde meine Domain-Modelle (ganze Aggregate) wird als JSON-Dokument serialisiert werden könnten und in einem DB gespeichert.

Ja, das ist gut.

Aber was ist mit dem Lesen der Daten für den Zweck der Anzeige auf dem Bildschirm. Meine Benutzeroberfläche zeigt Ansichten basierend auf Ansichtsmodellen an, aber wie werden sie erstellt? Abfrage ich den Dokument-DB über. mein Domain-Modell und dann ordnen Sie es zu Modell anzeigen?

Ja. Die interessante Frage ist wenn.

Sie können dies synchron mit der Anfrage arbeiten.

Sie können dies synchron mit der Anforderung ausführen, aber das Ergebnis zwischenspeichern, sodass nachfolgende Abfragen der gleichen Ansicht schneller sind.

Sie können das asynchron arbeiten - Hintergrundprozesse verwenden, um Ansichten in den Cache zu laden, so dass alle Abfragen schnell sind.

Die Grundidee ist, dass Sie jedes Mal, wenn Sie eine Änderung an dem Dokument schreiben, dem asynchronen Prozess signalisieren, dass eine Änderung stattgefunden hat, und dann lädt der Prozess die Daten, die zum Aktualisieren der zwischengespeicherten Ansicht benötigt werden.

Der "Cache" kann beispielsweise ein Dokumentenspeicher sein, der das zuletzt erstellte Ansichtsmodell enthält.

Die zwischengespeicherte Ansicht enthält möglicherweise auch Metadaten, die es ermöglichen, zum Zeitpunkt der Anforderung zu ermitteln, ob die Ansicht neu erstellt werden muss. RFC 7234 ist wahrscheinlich ein guter Anfang, wenn Sie über Cache-Metadaten nachdenken. Wie Pawel bemerkte, ist die Trennung des Schreibmodells und des Lesemodells das große Thema von cqrs. Es ist ruhig eine Menge Literatur verfügbar. Ich würde vorschlagen, ausgehend von Martin Fowler's overview.

Answer 2

Es ist wichtig zu verstehen, dass Ihr Domänenmodell sowohl aus Verhalten als auch aus Zustand besteht. Das Einzige, was du fortbestehen musst, ist der Staat.

Wenn Sie dies erkennen, werden Sie auch herausfinden, dass ein Aggregatzustand nicht etwas beängstigend ist, um Ihre Abfragen auszuführen. Aber Sie sollten Ihre Repositories definitiv nicht verwenden, um Lese-/Ansichtsmodelle zu erstellen - einfache Abfragen würden ausreichen.Dort ist es praktisch, den Status Ihrer Domänenobjekte in einfache DTOs (Dokumente) aufzuteilen, die Sie in der Datenbank speichern und als Eigenschaften in Ihren Domänenobjekten speichern. Dies ist ein bisschen anders als in dem Buch gezeigt, aber in der Praxis funktioniert es gut. Sie werden zumindest aufhören, sich Sorgen zu machen, wenn Sie gut genug kapseln und Serialisierungs- und Persistenztests nicht schreiben. This article erwähnt es unter dem Domain-Objekt, das durch ein State Object Abschnitt unterstützt wird.