Ist es möglich, die DDD- und REST-Schnittstelle und die Sprachzuordnung zu erstellen?

Question

REST hat eine einheitliche Schnittstellenbeschränkung, die in einem sehr gezippten, meinungsbasierten Format folgt.

• Sie haben Standards zu verwenden, wie HTTP, URI, MIME, etc ...
• Sie haben Hyperlinks zu verwenden.
• Sie müssen RDF-Vokabeln verwenden, um Daten und Hyperlinks mit Semantik zu kommentieren.
• Sie alle diese, um den Client von den Implementierungsdetails des Dienstes zu entkoppeln.

DDD mit CQRS (oder ohne es) ist sehr ähnlich, soweit ich verstehe.

Mit CQRS definieren Sie eine Schnittstelle für die Interaktion mit dem Domänenmodell. Diese Schnittstelle besteht aus Befehlen und Abfragen Klassen.

Mit DDD definieren Sie Domänenereignisse, um das Domänenmodell von den Persistenzdetails zu entkoppeln.

Durch DDD haben Sie eine allgegenwärtige Sprache pro begrenztem Kontext, die die Semantik ausdrückt.

Sie tun dies, um das Domänenmodell vollständig von der Außenwelt zu entkoppeln.

Ist es möglich, die einheitliche REST-Schnittstelle der Domänenschnittstelle zuzuordnen, die durch Befehle und Abfragen und Domänenereignisse definiert wird? (Der REST-Servicecode würde also automatisch generiert.)

Ist es möglich, die verknüpfte Datensemantik den ubiquitären Sprachen zuzuordnen? (Sie müssten also keine sehr ähnlichen Begriffe definieren, sondern einfach vorhandene Vokabeln suchen und wiederverwenden.)

Fügen Sie Ihrer Antwort ein sehr einfaches Zuordnungsbeispiel hinzu, warum ja oder warum nicht!

Answer 1

Ich glaube nicht, dass dies möglich ist. Es gibt einen Begriff, den ich glaube, beschreibt dieses Problem, es heißt ontology alignment.

In diesem Fall müssen mindestens 3 Ontologien:

• die allgegenwärtige Sprache (UL) des Domänenmodells
• die anwendungsspezifische vocab (ASO) des REST-Dienst
• die offene verbunden Daten Vocabs (LODO), die die anwendungsspezifische vocab

verwendet So haben wir mindestens zwei Ausrichtungen:

• die UL: ASO Ausrichtung
• die ASO: LODO Ausrichtung

Unser Problem mit dem UL zusammenhängt: ASO Ausrichtung, also lassen Sie uns über diese Ontologien sprechen.

Die UL ist objektorientiert, weil wir über DDD und Domain-Modell sprechen. Die meisten Domänenobjekte entities, value objects sind also reale Objekte und keine Datenstrukturen. Der nicht-objektorientierte Teil davon sind die DTOs wie command+domainEvent, query+result und error auf der Schnittstelle des Domänenmodells.

Im Gegensatz dazu ist die ASO streng prozedural, wir manipulieren die Ressourcen (Datenstrukturen) mit einer Reihe von Standardmethoden (Prozeduren) auf ihnen.

Also von meinem Aspekt sprechen wir über zwei sehr verschiedene Dinge, und wir haben die folgenden Optionen:

• die ASO mehr objektorientierte machen -> RPC
• die UL weniger objektorientiert machen -> anämisch Domain-Modell

So aus meiner Sicht wir folgende Dinge tun:

• können wir automatisch Entitäten Ressourcen und Befehle zu Operationen von CRUD zuordnen, zum Beispiel die HydraBundle macht dies mit aktiven Datensätzen (wir können genau das gleiche mit DDD und ohne CQRS)

• wir können Befehle manuell zuordnen Operationen von a komplexe Domänenmodell

  • die Operation POST transaction {...} kann Ergebnis eine SendMoneyCommand{...}
  • die Operation GET orders/123/total einen OrderTotalQuery{...}
• führen

  wir können nicht durch eine komplexe Domänenmodell Entitäten Ressourcen abzubilden, weil wir neue Ressourcen definieren müssen, um einen neuen Dienst oder eine neue Einheit Methode zu beschreiben, zum Beispiel

  • der Betrieb POST transaction {...}account.sendMoney(anotherAccount, ...)
  • der Betrieb zur Folge haben kann GET orders/123/total kann, ohne jemals in einer SQL-Abfrage auf einer Lese Datenbank führt eine einzelne Einheit

zu berühren ich denke, es ist nicht möglich, diese Art von Ontologie Ausrichtung Wette zu tun ween DDD + CQRS und REST, aber ich bin kein Experte für dieses Thema. Ich denke, wir können einen anwendungsspezifischen Vokabular mit Ressourcenklassen, Eigenschaften und Operationen erstellen und die Operationen den Befehlen/Abfragen und den Eigenschaften den Befehls-/Abfrageeigenschaften zuordnen.

Answer 2

Sie haben hier einige interessante Fragen gestellt.

Anfangs habe ich mit

von DDD definieren Sie Domain-Ereignisse zu entkoppeln den Domain-Modell aus den Persistenz Details nicht ganz einverstanden.

Ich glaube, Sie könnten Event Sourcing ES mit DDD verwirrend sein kann ES mit DDD verwendet werden, aber es ist sehr viel optional in der Tat sollten Sie ihm eine Menge Gedanken geben, bevor es als Persistenzmechanismus wählen.

Nun zum Großteil Ihrer Frage, ob REST und DDD miteinander auskommen, wenn ja wie?

Ich nehme an, ja, sie verstehen sich, aber im Allgemeinen wollen Sie nicht Ihr Domain-Modell über eine REST-Schnittstelle offen legen, Sie wollen eine Abstraktion darüber erstellen und diese dann freilegen.

Sie können auf diese Antwort here, für ein wenig mehr Details beziehen.

Allerdings kann ich das Implementing Domain-Driven Design Buch nicht genug empfehlen, Kapitel 14 Anwendung beschäftigt sich mit Ihrem Anliegen zu einem fairen Grad.

ich es gründlicher als das Buch nicht hätte erklären und man daher dort Bezug :)