Welche Schicht für Domain-Events, Eventhandler, Dispatcher

Question

Ich habe gelesen, über Domain Events und haben Codes von Udi-Implementierung ( http://www.udidahan.com/2009/06/14/domain-events-salvation/ ) Mike Hadlow ( http://mikehadlow.blogspot.com /2010/09/separation-of-concerns-with-domain.html ), Jimmy Bogard und Jason Dentler Implementierung.

Alles in allem Ich mag die Idee von Veranstaltungen.

Meine Fragen sind, welche Schicht soll ich diese Komponenten hinzuzufügen.

Ich bin kein Bus verwenden gehen und alle Veranstaltungen werden in synchroner Weise gehandhabt werden .

Ich denke, die Schnittstelle IDomainEvent sollte IEventHandler in gehen Project.Core , wo Rest der Schnittstellen gehalten und von allen Projekten abgerufen.

Der Dispatcher (die eine statische Klasse ist), ich sollte in gehen glauben Project.Infrastructure .

werde ich ein neues Projekt nur für Handlers von Domain-Ereignissen erstellen. können sagen, Project.EventHandlers .

verwende ich IoC (StructureMap) alle Handler zu registrieren.

Die Ereignisse selbst, wie ich sehe auf Business Sprache basieren und aus diesem Grunde glaube ich, gehen sollte Project.Domain in der alle Aggregate umgesetzt werden.

Lassen Sie mich wissen, ob dies der richtige Weg ist.

Meine andere Verwirrung ist auf Projektreferenzen. Should Project.Domain Hinweis Project.Infrastructure , so dass es die statische verwenden können Event-Dispatcher .

Should Project.EventHandlers Hinweis Project.Domain , weil es muss wissen, was Ereignisse sind, dass gehandhabt werden kann.

Ich plane eine StructureMap Registry-Klasse in Project.EventHandlers zu erstellen, die dann in Global.asax Bootstrap wird.

Wenn dies bitte vorher Punkt gesprochen wurde mir auf den Link. Ich konnte nicht ein durch Google-Suchen finden.

Answer 1

Sind diese Projekte oder Namespaces? Es gibt eine alte und die laufende Debatte über feinkörnig Verse Projektstruktur grobkörnig. Ich bin in dem grobkörnig Lager. Eine Baugruppe ist eine Einheit der Bereitstellung, nicht eine logische Schicht und die Struktur, die Sie beschreiben, ist besser als Namensraum in einem einzigen Projekt erreicht.

Having said that, Ihre Organisation sinnvoll aussieht. Meine einzige Änderung Schnittstellen neben ihren Implementierungen zu setzen wäre, anstatt in Project.Core.