Warum sollte das Domänenmodell nicht als Ressource in der REST-API verwendet werden?

Question

Ich stieß auf eine Aussage, dass das Domänenmodell, das in Übereinstimmung mit DDD entworfen wurde, nicht als Ressourcen in einer REST-API() verwendet werden sollte.

Es ist klar, dass eine REST-API ein Vertrag der Anwendung ist, während das Domänenmodell Teil der Implementierung ist. Daher ist es am besten, diese beiden Dinge getrennt zu halten, damit eine Änderung im Domänenmodell nicht automatisch erfolgt implizieren eine Änderung in der REST-API.

Allerdings denke ich, dass bei kleinen Projekten (wo die REST API nur einen Kunden hat - das JavaScript Frontend, entwickelt von einem Team) die Vorteile getrennter Modelle nicht die Kosten für die Trennung der Modelle (verschiedene Klassen) rechtfertigen - Domänenmodell und Ressourcendarstellungen und Mapping-Code zwischen den Modellen. Offensichtlich kann der Domänen-Layer keine Verweise auf REST-spezifischen Infrastruktur-Code enthalten (um die Trennung von Bedenken zu vermeiden).

Sollen die Domäne und die REST-Modelle getrennt werden?

Answer 1

Bei Verwendung von DDD sollte die REST-API immer vom Domänenmodell getrennt sein.

Der Hauptgrund dafür ist die Vereinfachung - Sie möchten die Komplexität des Domänenmodells nicht über die API an die Clients weitergeben. Andernfalls müssen die Kunden die Nuancen und Feinheiten Ihrer Domain kennen, wodurch die API höchstwahrscheinlich schwer zu verwenden ist.

Und der Haupttreiber für die Verwendung von DDD ist eine komplexe Problemdomäne, das ist also immer ein Problem.

Aber ich denke, bei kleinen Projekten (& hellip;) die Vorteile der getrennten Modelle mit rechtfertigt nicht die Kosten, die Modelle der Trennung (& hellip;).

Ich stimme zu, dass es Projekte gibt, bei denen ein getrenntes Domänenmodell und eine REST-API übertrieben sind. Diese Fälle sind jedoch keine Kandidaten für DDD, da Sie nicht von DDD genug profitieren, um seine Kosten zu rechtfertigen.

Answer 2

Ich denke, eine andere Sache zu prüfen ist, wer Ihre REST API verwendet. Wenn Sie ein Frontend für eine App entwickeln, dann können Sie sagen, dass alles noch innerhalb eines beschränkten Kontextes geschieht. Nur ein Teil lebt in Client/Javascript. In diesem Fall denke ich, dass es sinnvoll ist, Ihr Modell in Ihrer Ruhepi zu exponieren.

In diesem Fall könnte die REST API nur ein Mittel zur Kommunikation mit Ihren Domain-Services sein.

Answer 3

Warum sollte das Domänenmodell nicht als Ressource in REST API verwendet werden?

Da das Web eine völlig andere Welt als Ihre Core-Domain-Ebene ist. Die Methoden in Ihren Entitäten sind besonders schwer zu übersetzen, da HTTP nur eine Handvoll Verben hat. Wenn Sie Ihre Anwendung über REST verfügbar machen möchten, müssen Sie Ihre Domain-Prozesse in HTTP einteilen, was normalerweise bedeutet, dass Sie Kompromisse eingehen und Ressourcen entwerfen, die sich von Ihren Domain-Entitäten unterscheiden.

Natürlich sollten Sie Begriffe aus der Ubiquitous Language in den Nachrichten finden, die zwischen dem HTTP-Client und -Server und im Domain Application Protocol ausgetauscht werden, wenn Sie HATEOAS ausführen, aber das Web wird Ihre Domain-Darstellungen notwendigerweise verzerren.

Der Punkt von REST besteht nicht darin, ein High-Fidelity-Modell Ihrer Domäne und ihrer Prozesse neu zu erstellen, sondern HTTP-kompatibel zu liefern und dabei so wenig wie möglich in der Übersetzung zu verlieren. Dennoch bleibt es eine Übersetzung.

Answer 4

Sie können Ihre Geschäftslogik basierend auf Ihrem Domänenmodell in Ihre REST-Ressourcen einbinden. Zum Beispiel, wenn jemand is_published = 1 setzt, können Sie einen Administrator benachrichtigen, eine zusätzliche Validierung durchführen usw., indem Sie sich in ein Ereignis oder einen Mutator einklinken. Manchmal sind die Dinge zu kompliziert und seltsam, um dies zu tun. Sie können also bestimmte Attribute als nicht änderbar kennzeichnen und dann benutzerdefinierte Aktionen erstellen, um sie zu ändern, wenn Sie das tun, wenn dies sinnvoll ist. Ich denke, wenn Sie richtig entwerfen, brauchen Sie diese "benutzerdefinierten Aktionen" nicht einmal. Facebook verwendet keine mit der Graph API, glaube ich nicht. Ich denke darüber nach, ein Framework zu entwickeln, das darauf basiert, die Model-Ebene bloßzustellen, ich denke immer noch, dass es eine gute Idee ist.