Naming Convention for Commands & Events

Question

I'm just getting into event-driven architectures and would like to know what the convention is for naming commands and events. I know this much: Commands should be in the form DoSomething while events should be in the form SomethingHappened. What I need to clarify is if I need to append the word 'Command' to my commands and 'Event' to my events e.g. DoSomethingCommand as opposed to just DoSomething and SomethingHappenedEvent as opposed to just SomethingHappened. I would also like to know what the rationale is behind the community-preferred convention. Thanks!

Thanks! Just did so. Took a little while to figure out how to. — Tolu, Sep 28 '12 at 09:53
As a rule of thumb, commands should contain an action verb, e.g. InitiatePayment, while an event should be in its past tense form, e.g. PaymentInitiated — panza, Aug 18 '22 at 08:10

eulerfx · Accepted Answer · 2012-09-21T14:18:29.517

21

The Command and Event suffixes are optional and are a matter of preference. I prefer to omit them and try to make the intent evident from the name alone. The most important aspect of naming commands and events is making sure they reflect the business domain more so than the technical domain. A lot of times terms like Create, Update, Add, Change are far too technical and have less meaning in the business domain. For example, instead of saying UpdateCustomerAddress you can say RelocateCustomer which could have a larger business context to it.

edited Sep 21 '12 at 14:18

answered Sep 21 '12 at 02:41

eulerfx

36,769
7
61
83

Thanks, I've started implementing using this approach. I also like @MikaelÖstberg's point about using namespaces. A minor point I did notice though was the fact that appending Event/Command did seem to read better when instantiating the object. Compare: `var userSignedOut = new UserSignedOut() { };` `bus.Publish(userSignedOut);` with `var userSignedOutEvent = new UserSignedOutEvent() { };` `bus.Publish(userSignedOutEvent);` – Tolu Oct 02 '12 at 09:30

score 16 · Answer 2 · answered Sep 20 '12 at 10:26

16

My convention is depending on namespaces and by that I mean that I never use the suffix Event nor Command.

I also organise commands and events into separate namespaces based on the aggregate type they are meant to affect.

Example:

// 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

Depending on your requirements you might want to place your events into a separate assembly. The reason for this would be if you need to distribute events to downstream systems. In that case you probably don't want downstream systems to have to bother about your commands (because they shouldn't).

answered Sep 20 '12 at 10:26

Mikael Östberg

16,982
6
61
79

Thanks a lot, @mikael. This makes a lot of sense and is the direction in which I'm currently leaning. I just wanted to clarify what the standard practice is. – Tolu Sep 20 '12 at 10:43
I wouldn't say that this is standard practice. This is just the way I do it. However, I think this follows .Net conventions making use of namespaces as part of the full name and not repeating yourself with suffixes and stuff. The only downside is that resharper offers a whole lot of options when you want add a using statement for one of the 20 something events called `Created`. – Mikael Östberg Sep 20 '12 at 11:07
I tend to separate my commands and events into separate assemblies and use different namespaces as @MikaelÖstberg described above. I wouldn't advocate for tacking Command or Event at the end of those messages, either. +1 – David Hoerster Sep 20 '12 at 20:16
@MikaelÖstberg if your command for creating a customer fails, in terms that the payload was missing a value, would you still send the event Created? If not, what event would you send instead? – dirbacke Feb 19 '20 at 13:48
I wouldn’t create the customer. I would throw an exception and let the command end up in the error queue. – Mikael Östberg Feb 19 '20 at 17:05

score 7 · Answer 3 · answered Sep 24 '12 at 14:07

The convention that I've seen a lot and use myself is that events should be in past tense and described what happened:

UserRegistered
AccountActivated
ReplyPosted

Commands is something that you would like to do. So create names that illustrate that:

CreateUser
UppgradeUserAccount

As for organization, I usually put them together with the root aggregate that they are for. It makes it a lot easier to see what you can do and what kind of events that are generated.

That is, I create a namespace for each root aggregate and put everything under it (repository definition, events, commands).

MyApp.Core.Users
MyApp.Core.Posts

etc.

score 6 · Answer 4 · answered Sep 24 '12 at 02:44

Commands and Events form a language for your application...an API. The use of terms like 'command' and 'event' are perhaps useful for system-level definitions where technical terms are meaningfully mixed into an entity's purpose, but if you are dealing with definitions for Domain behavior's, then drop the system/technical terminology and favor the business-speak. It will make your code read more naturally and lessen typing. I started with the 'Command'/'Event' appendages but realized it was a waste of time and drew me away from the Ubiquitous Language DDD popularized. HTH, Mike

score 4 · Answer 5 · answered Sep 21 '12 at 06:18

4

Appending Command and Event would be redundant information if yor commands/events are properly named. This would be noise that makes your code less readable. Remember Hungarian Notation? Most programmers (that I know of) don't use it anymore.

answered Sep 21 '12 at 06:18

Dennis Traub

50,557
7
93
108

Naming Convention for Commands & Events

5 Answers5