DDD - Speichern von Domänenobjekten in dokumentorientierten Speichern, PostgreSQL, MongoDB

Question

Noch eine Frage zu DDD. Ich dachte daran, meine Aggregate zu behalten (ich möchte Event Sourcing nicht verwenden). Ich suchte im Internet nach und fand sehr interessant article von Vaughn Vernon. Kurz gesagt - der Autor lobt das Konzept der Speicherung von Domain-Objekten mit der gesamten Struktur unter Verwendung von Dokumenten-orientierten Speichern, insbesondere PostgreSQL.

Meine Frage ist - wie ich neu zu DDD-Konzept bin - ist es üblich in DDD-Entwicklung diesen Ansatz zu verwenden? Ich meine, Aggregate als serialisierte vollständige Dokumente mit dokumentorientiertem Speicher zu speichern? Ich denke, persistente Aggregate in ihrer verschachtelten Weise ist näher an DDD Idee, als Laden und Mapping mit ORM. Das Dokumentformat scheint für die geschachtelte Struktur von Domänenobjekten natürlicher und elastischer zu sein. Neben dem oben genannten Artikel finde ich noch einige Kommentare zu diesem Konzept.

Die nächste Frage ist - in PHP-Umgebung - hat jemand versucht, es mit Doctrine2 zu verknüpfen? Es scheint, es könnte automatisch POPOs serialisieren und es ist möglich, ValueObjects in irgendeiner Weise zu verwenden.

Vielen Dank im Voraus!

Answer 1

Meine Frage ist - wie ich neu zu DDD-Konzept bin - ist es üblich in DDD-Entwicklung, diesen Ansatz zu verwenden?

Ja - ish.

Eine Sache zu beachten: DDD soll helfen, das Geschäft korrekt zu modellieren. Wenn Änderung ist eine wertvolle Eigenschaft für die Domäne zu haben (wahrscheinlich der Fall sein, wenn dieses Projekt ist ein Wettbewerbsvorteil für Ihr Unternehmen), dann müssen Sie über aggregierte Serialisierung, die leicht zu verbesserten Modellen migriert werden . Mit anderen Worten, wie ordnen Sie dem neuen Modell eine Repräsentation des alten Modells zu?

Wenn Sie diesen Ansatz verwenden, können Sie auch in cqrs schauen; Blobs von Daten sind befriedigend für die Schreib-Anwendungsfälle, aber nur Write-Domain-Modelle bieten wenig Geschäftswert. Möglicherweise haben Sie es leichter, ein möglicherweise konsistentes Lesemodell zu entwickeln, anstatt komplexe Prognosen nach Bedarf aus einem Dokumentenspeicher zu erstellen.

Der andere Ort, an dem Sie einen ähnlichen Ansatz sehen, sind Lösungen, die ereignisbezogene Aggregate verwenden. Schreibvorgänge werden durch Anhängen an eine Historie erreicht, und der tatsächliche Zustand, der an einer gegebenen Änderung beteiligt ist, wird normalerweise in einem Blob gespeichert.

Answer 2

Wie Sie vielleicht aus dem Buch wissen, wird die Persistenz von Aggregaten mithilfe des Repository-Musters durchgeführt. Sein Zweck besteht darin, Persistenztechnologie und Implementierungsdetails aus dem Domänenmodell zu verbergen.

Repositorys können nach Definition nur ganze Aggregate speichern und abrufen. Aus diesem Grund erwähnt Vernon die dokumentartige Speicherung als einen guten Kandidaten. Wenn Sie RDBMS für die Gesamtpersistenz verwenden, verwenden Sie häufig ORMs und komplexe Zuordnungen. Wenn Sie diesen Pfad verwenden, erhalten Sie komplexe Schemas und nicht optimale Abfragen, umständliche Aktualisierungslogik und so weiter.

Dies ist in der Tat, warum CQRS vor allem in der DDD-Community an Bedeutung gewann, weil traditionelle Sammlungs-Repositories nicht in der Lage sind, viele Aggregate abzufragen und einige "reporting-style" -Daten abzurufen. Das blaue Buch deutet auf einen ziemlich komplexen Weg hin. CQRS beseitigt dieses Problem, erfordert jedoch einige zusätzliche Arbeit, um zwei Modelle synchronisiert zu halten.

Es gibt auch einen anderen Ansatz, um damit umzugehen. Normalerweise muss das Domänenmodell keine Abfragen für Aggregate ausführen. Ein "Client" des Domänenmodells ist dafür verantwortlich, einen geeigneten "Befehl" oder eine Anforderung an das Domänenmodell zu senden, das von einer Art von Anwendungsdienst verarbeitet werden soll. Dieser "Client" -Teil oder "Adapter" -Teil in der hexagonalen Architektur kann Abfragen in der Domain-Persistenz-Datenbank ausführen, ohne irgendwelche Repositories zu verwenden. Es ist eine Art CQRS, aber mit einer Datenbank.