2016-04-10 6 views
1

Ich versuche, mein Verständnis von DDD zu fördern. Genauer gesagt, wie man Domain-Events über einen Nachrichtenbus für die asynchrone Verarbeitung behandelt.Wo lebt der Nachrichtenbus-Dienst in Domain Driven Design

Lets sagen, dass ich etwas Architektur haben ->

_____________________ 
|      | 
|  Client  | 
|_____________________| 
      | 
__________|__________ 
|      | 
| Application Service | 
|_____________________| 
      | 
__________|__________ 
|      | 
|  Domain  | 
|_____________________| 

Wenn meine Domain einige Domain-Ereignis auslöst, wie bekomme ich dieses Ereignis zu einem Messaging-Dienst wie RabbitMQ?

Mein erster Gedanke ist es, eine Nachricht Bus-Service, IMessageBus, , die weiß, wie die Ereignisse zu RabbitMQ senden injizieren. Der Dienst würde von Domäne-Ereignishandlern verwendet, um das Ereignis an den Bus zu senden.

Aber dann dachte ich, jetzt muss meine Domäne wissen, wie sie mit ihren eigenen Ereignissen umgehen soll.

Kann jemand etwas Licht in die Sache bringen?

Antwort

3

Der Servicebus ist Teil der Infrastruktur, jedoch wissen die Anwendungsdienste (als Abstraktion) darüber. Es ist in Ordnung, den Bus in den App-Dienst zu integrieren, da der App-Dienst keine Domänenlogik enthält, sondern als Koordinator und Host eines Geschäftsanwendungsfalls fungiert.

Aber dann dachte ich, jetzt muss meine Domäne wissen, wie sie mit ihren eigenen Ereignissen umgehen soll.

Ja, aber der Bus liefert nur die Nachrichten, die Nachrichtenhandler sind im Grunde Anwendungsdienste.

Rabbit und andere sind eine Implementierungsdetails, Ihre App-Handler sollten vom Service-Bus aufgerufen werden (was den eigentlichen Messaging-Prozess abstrahieren sollte).

+0

Wo lebt die Abstraktion des Busses? Leben alle Abstraktionen in der Domäne, selbst die, die nur in der Anwendungsschicht verwendet wird? Ich vermute, dass dies der Fall sein kann, wenn man bedenkt, dass Sie nie wissen werden, wann sich die Logik in einem Domain-Service bewegt? – plalx

+0

Die Abstraktion des Busses ist Teil der Busdefinition. Der App-Dienst verwendet ihn wie einen externen Dienst. Ein wichtiger Punkt ist, dass es sich bei dem App-Service um eine Domain-Fassade handelt, die nicht wirklich Teil der Domain selbst ist. Wenn Sie die App-Dienste in der Domäne definieren, gehören Dinge wie die Repository-Schnittstelle dazu, aber nur als technisches Detail. Aber die Busabstraktion sollte nicht Teil der Domain oder gar der App selbst sein. Schließlich ist ein Servicebus eine unabhängige Komponente, die Ihre App benötigt. – MikeSW

+0

Ich bin mir nicht sicher, ob ich deine Erklärung richtig verstehe. Unter Abstraktionen verstehe ich im Grunde Schnittstellen.Normalerweise würden Sie Schnittstellen wie Repository-Schnittstellen in der Domäne deklarieren und sie in der Infrastrukturschicht implementieren. Die Anwendungsschicht würde dann von der Schnittstelle abhängen, mit Ausnahme der Kompositionswurzel, die ebenfalls von der Infrastrukturschicht abhängen würde. Dies ist sinnvoll, da eine Repository-Schnittstelle von einem Domain-Service verwendet werden kann. Daher sollte auch die Message-Bus-Schnittstelle in der Domain deklariert werden? – plalx

1

Diese Frage ist analog zu "wie kommuniziert Ihre Domäne mit einem externen System (außer für Datenpersistenz)"?

Ein Service-Bus unterscheidet sich nicht von einem physischen Sensor oder einer anderen externen Hardware. Typischerweise repräsentiert man diese physischen Dinge im Code als ein Objekt, das das physikalische Konzept abstrahiert. Sie befinden sich außerhalb der Problemdomäne (PD) und können als Systemintegrationsobjekte (SI-Objekte) betrachtet werden.

Wenn Ihre Domäne mit einem externen System kommunizieren muss, ruft sie einfach das entsprechende SI-Objekt ab. Ebenso kann ein SI-Objekt Ihre Domain aufrufen.

Hinweis: Diese Antwort geht davon aus, dass Ihre Domain nicht anämisch ist.

Verwandte Themen