2016-07-28 26 views
1

Im Rahmen meines Application Service, ich habe den folgenden Code für die Veröffentlichung von Domain-Ereignissen abonnieren:Wo Domain Ereignisse

var document = await dbContext.Documents.GetAggregateAsync(message.DocumentId); 

publisher.SubscribeTo<DocumentOwnerChanged>() 
    .UsingDelegate(
     async a => await messageGateway.DocumentOwnerChanged(1, 1, 1)); 

document.ChangeOwner(message.OwnerId); 

await dbContext.SaveChangesAsync(); 

await publisher.Publish(document.ReleaseEvents()); 

Ich versuche zu entscheiden, ob ich mag es, dieses Wissen der Veröffentlichung Ereignisse innerhalb des App-Service oder wenn ich das irgendwo in der Wurzel höher externalisieren sollte.

Gedanken?

Antwort

3

Normalerweise würden Sie Handler im Composition Root registrieren, es sei denn, Sie mussten Handler anhand anderer Nachrichten dynamisch registrieren und die Registrierung aufheben.

Es gibt einige Diskussionen um dieses here

würden Sie Domain Ereignisse normalerweise in Ihrer Domain Schicht veröffentlichen:

public void SomeDomainBehaviour() 
{ 
    // do something domain-y 
    DomainEvents.Publish(new DomainEvent()); 
} 

Jimmy Bogard diskutiert andere Möglichkeiten der Veröffentlichung Domain Events here

+0

Ihnen danken Ich bevorzuge die Rückgabe/Speicherung von Ereignissen im Gegensatz zum statischen Publisher. – Marco

+0

Jimmys Artikel ist großartig. Ich habe ein Muster angenommen, das auf seinem basiert, in diesem Artikel. Mein einziges persönliches Problem ist, dass mehrere Aggregate an einer einzigen Transaktion teilnehmen können. Ich habe mich mehr für eine mögliche Konsistenz entschieden, auf die Jimmys Artikel immer noch anspielt, wenn Sie den base.Save() - Aufruf zu Beginn der Überschreibung setzen und dann Ihre Ereignisse versenden. Das ist IMO, eine viel bessere Lösung als ein asynchroner Versand. Die Handler können asynchron ausführen, aber ich würde gerne wissen, ob ein Ereignis persönlich nicht veröffentlicht werden konnte. –