2012-09-20 20 views
10

Ich komme gerade in ereignisgesteuerte Architekturen und möchte wissen, was die Konvention für die Benennung von Befehlen und Ereignissen ist. Ich weiß so viel: Befehle sollten in der Form DoSomething sein, während Ereignisse in der Form SomethingHappened sein sollten. Was ich klären muss, ist, ob ich das Wort "Befehl" an meine Befehle und "Ereignis" an meine Ereignisse anhängen muss, z. DoSomethingCommand im Gegensatz zu DoSomething und SomethingHappedEvent im Gegensatz zu nur SomethingHappened. Ich würde auch gerne wissen, was die Gründe für die von der Gemeinschaft bevorzugte Konvention sind. Vielen Dank!Namenskonvention für Befehle und Ereignisse

+0

Dank! Habe es gerade getan. Es dauerte eine Weile, um herauszufinden, wie. – Tolu

Antwort

12

Die Command und Event Suffixe sind optional und sind eine Frage der Präferenz. Ich ziehe es vor, sie wegzulassen und zu versuchen, die Absicht aus dem Namen allein zu machen. Der wichtigste Aspekt bei der Benennung von Befehlen und Ereignissen besteht darin, sicherzustellen, dass sie die Geschäftsdomäne stärker widerspiegeln als die technische Domäne. Begriffe wie "Erstellen", "Aktualisieren", "Hinzufügen" und "Ändern" sind oft viel zu technisch und haben in der Geschäftsdomäne weniger Bedeutung. Anstatt UpdateCustomerAddress zu sagen, können Sie beispielsweise RelocateCustomer sagen, was einen größeren Geschäftskontext haben könnte.

+0

Danke, ich habe damit begonnen, diesen Ansatz zu implementieren. Ich mag auch @ MikaelÖstbergs Punkt über die Verwendung von Namespaces. Ein kleiner Punkt, den ich bemerkte, war die Tatsache, dass das Anhängen von Event/Command beim Instanziieren des Objekts besser zu lesen schien. Vergleichen Sie: 'var userSignedOut = new UserSignedOut() {};' ' bus.Publish (userSignedOut);' mit 'var userSignedOutEvent = new UserSignedOutEvent() {};' ' bus.Publish (userSignedOutEvent); ' – Tolu

8

Meine Konvention ist abhängig von Namespaces und damit meine ich, dass ich niemals das Suffix Event nor Command verwende.

Ich organisiere auch Befehle und Ereignisse in separate Namespaces basierend auf dem Aggregat-Typ, den sie betreffen sollen.

Beispiel:

// Commands 
MyApp.Messages.Commands.Customers.Create 
MyApp.Messages.Commands.Orders.Create 
MyApp.Messages.Commands.Orders.AddProduct 

// Events 
MyApp.Messages.Events.Customers.Created 
MyApp.Messages.Events.Orders.Created 
MyApp.Messages.Events.Orders.ProductAdded 

Je nach Ihren Anforderungen Sie möchten Ihre Veranstaltungen in eine separate Baugruppe platzieren. Der Grund dafür wäre, wenn Sie Ereignisse an nachgelagerte Systeme verteilen müssen. In diesem Fall möchten Sie wahrscheinlich nicht, dass sich nachgelagerte Systeme um Ihre Befehle kümmern müssen (weil sie dies nicht sollten).

+0

Vielen Dank @mikael. Das macht sehr viel Sinn und ist die Richtung, in der ich mich gerade lehne. Ich wollte nur klarstellen, was die Standardpraxis ist. – Tolu

+0

Ich würde nicht sagen, dass dies gängige Praxis ist. So mache ich es. Aber ich denke, das folgt .Net-Konventionen, die Namespaces als Teil des vollständigen Namens verwenden und sich nicht mit Suffixen und Zeug wiederholen. Der einzige Nachteil ist, dass Resharper eine ganze Reihe von Optionen bietet, wenn Sie eine using-Anweisung für eines der 20 Ereignisse namens 'Created' hinzufügen wollen. –

+0

Ich neige dazu, meine Befehle und Ereignisse in separate Assemblies zu trennen und verschiedene Namespaces zu verwenden wie @ MikaelÖstberg oben beschrieben. Ich würde auch nicht dafür eintreten, Command oder Event am Ende dieser Nachrichten anzuheften. +1 –

3

Das Anhängen von Befehl und Ereignis wäre eine redundante Information, wenn Ihre Befehle/Ereignisse korrekt benannt sind. Dies wäre ein Rauschen, das Ihren Code weniger lesbar macht. Erinnere dich an die ungarische Notation Die meisten Programmierer (die ich kenne) benutzen es nicht mehr.

3

Befehle und Ereignisse bilden eine Sprache für Ihre Anwendung ... eine API. Die Verwendung von Begriffen wie 'Befehl' und 'Ereignis' sind möglicherweise nützlich für Definitionen auf Systemebene, bei denen technische Begriffe sinnvoll in den Zweck einer Entität gemischt werden. Wenn Sie jedoch mit Definitionen für Domänenverhalten arbeiten, löschen Sie die System-/Fachterminologie favorisieren das Geschäft sprechen. Dadurch wird Ihr Code natürlicher und weniger schreibend. Ich begann mit den 'Command'/'Event' Anhängseln, erkannte aber, dass es Zeitverschwendung war und zog mich von der populären Ubiquitous Language DDD weg. HTH, Mike

1

Die Konvention, dass ich viel gesehen haben und nutzen, um mich ist, dass die Ereignisse in Vergangenheitsform sein sollte und beschrieben, was passiert ist:

  • UserRegistered
  • AccountActivated
  • ReplyPosted

Befehle ist etwas, was Sie tun möchten.So Namen erstellen, die zeigen, dass:

  • AngelegtVon
  • UppgradeUserAccount

Wie für die Organisation, ich sie in der Regel mit dem Root-Aggregat zusammen, dass sie da sind. Es macht es viel einfacher zu sehen, was Sie tun können und welche Art von Ereignissen generiert werden.

Das heißt, ich erstelle einen Namespace für jedes Root-Aggregat und alles darunter (Repository-Definition, Ereignisse, Befehle).

  • MyApp.Core.Users
  • MyApp.Core.Posts

usw.

Verwandte Themen