Ist ein Domänendienst in DDD im Wesentlichen nur ein Fassaden- und / oder Vermittlungsmuster?

In Domain Driven Design kann die Domänenschicht mehrere (traditionelle) Dienste haben. Für die Benutzerdomäne haben wir beispielsweise Folgendes:

Eine UserFactory, die Benutzerobjekte auf unterschiedliche Weise erstellt
Ein UserRepository, das für die Interaktion mit den Persistenzdiensten in der Infrastrukturschicht verantwortlich ist

Ist ein UserService in der Domänenschicht lediglich ein Vermittler und / oder eine Fassade für diese beiden Dienste und die Infrastrukturschicht, oder steckt mehr dahinter?

object-oriented object-oriented-design domain-driven-design

— e_i_pi
quelle

Siehe auch Dienste in DDD und Dienste in DDD

— Erik Eidt

Ich habe die Level Gorodinski-Beiträge viel gelesen, aber diesen zweiten Link noch nie gesehen. Tolle Lektüre, berührt definitiv einige wichtige Punkte!

— e_i_pi

Antworten:

Domain services werden am besten durch das beschrieben, was sie nicht sind:

sie sind weder EntitiesnochAggregate roots
Sie sind nicht Value objects
Tragen Sie Domain-Wissen, das natürlich nicht nur zu einem Entity oder einem passt Value object

Ein Beispiel für a Domain serviceist a Saga/Process manager: Es koordiniert einen lang laufenden Prozess, an dem mehrere beteiligt sind Aggregate roots, die von verschiedenen möglich sind Bounded contexts.

Abgesehen davon sind das, was ein ist Domain serviceund wie es implementiert wird, zwei orthogonale Dinge.

Ist ein UserService in der Domänenschicht lediglich ein Vermittler und / oder eine Fassade für diese beiden Dienste und die Infrastrukturschicht, oder steckt mehr dahinter?

Einige Domänendienste wie a UserRepository(bestehend aus einer in der Domain layerund einer konkreten Implementierung in der definierten Schnittstelle Infrastructure layer) können mithilfe des FacadeEntwurfsmusters implementiert werden . Andere Domain-Dienste sind nicht.

Es gibt keine feste Regel etwa , wie sie zu implementieren, ohne die wichtige Regel , dass der Domain layerMost hängt nicht von anderen Schichten (und SOLID ).

— Constantin Galbenu
quelle

Vielen Dank, ich glaube, ich verstehe endlich die Domänenschicht. Neben den Datenobjekten (Aggregate, Entitäten und Wertobjekte) enthält es auch die Geschäftsregeln - jedoch nicht die konkrete Implementierung dieser Regeln. Domänendienste definieren, was Sie mit Domänendatenobjekten tun können, wissen jedoch nicht, wie diese Vorgänge intern funktionieren.

— e_i_pi

@ e_i_pi-Geschäftsregeln werden nur von Aggregaten und ihren verschachtelten Entitäten geschützt. Domänendienste sind daran nicht beteiligt.

— Constantin Galbenu

@e_i_pi wobei die Operation mehr als ein Aggregat umfasst. Wenn beispielsweise die Liste der Bankkonten (Aggregate) einer Person (eines anderen Aggregats) gegeben ist, berechnet ein Domänendienst den Gesamtsaldo dieser Konten.

— Constantin Galbenu

@e_i_pi: Ich denke du hast ein paar Missverständnisse. Die gesamte Domänenschicht ist also ein Softwaremodell Ihrer Domäne. Sie sagten: "Zusammen mit dem Halten der Datenobjekte (Aggregate, Entitäten und Wertobjekte)" - dies sind keine "Datenobjekte" in dem Sinne, dass sie nur Daten enthalten. Diese implementieren tatsächlich Domänenregeln und definieren das Verhalten. Nun Domänendienste nach dem DDD Buch von E. Evans , sind die Aspekte der Domäne , die natürlicherweise nicht in ein Objekt passen (eine Einheit oder ein Wertobjekt).

— Filip Milovanović

Vielmehr wird ein Domänendienst "nur in Bezug auf das definiert, was er für einen Client tun kann", definiert in Bezug auf andere Elemente des Domänenmodells (also orchestriert er diese Elemente irgendwie und erzwingt Domänenregeln, die diese Orchestrierung regeln). Der Domänendienst selbst ist zustandslos. Es gibt auch das Konzept von Application Services , die sich auf einer höheren Ebene befinden und im Wesentlichen User Stories oder äquivalente Anwendungsfälle implementieren, indem sie als Schnittstelle zur Domänenebene fungieren. Beachten Sie, dass das Verhältnis von Objekten zu Diensten abhängig von der zu modellierenden Domäne variiert.

— Filip Milovanović

Ich sehe Dienste in DDD als Ergebnis der Abhängigkeitsinversion .

Wenn Sie "einfache" Abhängigkeiten verwenden würden, würde Ihr Domänencode die Datenbank aufrufen, um eine Entität oder Factory zu speichern oder abzufragen, die eine Entität erstellt, die an eine Datenbank oder einen externen Dienst oder einen anderen Infrastrukturcode gebunden ist.

Aber so sollte Domain-Code nicht sein. Der Domänencode sollte nicht vom Infrastrukturcode abhängen. Da diese Abhängigkeit das Testen und möglicherweise die Wiederverwendung erschwert. Deshalb kehren Sie diese Abhängigkeit um. Sie machen den Infrastrukturcode vom Domänencode abhängig. Und dazu müssen Sie eine Abstraktion einführen. Eine Abstraktion, die definiert, welches Verhalten der Domänencode voraussichtlich von der Infrastruktur implementiert wird.

Und Dienste in DDD sind diese Abstraktion. In den meisten Fällen sollten diese Dienste für Domänencode einfache Schnittstellen sein. Die Implementierung sollte im Infrastrukturcode erfolgen, der von diesen Schnittstellen abhängig ist.

— Euphorisch
quelle

Vielen Dank für Ihre Antwort, beide Antworten zusammen haben mir das "Aha!" Moment. Ich denke, ohne Ihre Antwort hätte ich das Konzept nicht vollständig verstanden, aber ich bevorzuge die Antwort von Constantine als Indikator für zukünftige Leser.

— e_i_pi