Messaging semantics: names and verbs

In most messaging systems I’ve worked with (synchronous or asynchronous), there are three general types of messages that arise:

  • Commands
  • Replies
  • Events

Queries can be thought of as a special kind of command where I ask for something and get a result. When moving from imperative languages to messaging patterns, it can be a bit of a leap to think in terms of interacting via messages, instead of just interacting with objects directly. In introducing messaging to developers, it’s common to have a bit of trouble making sure interactions match the message and naming semantics you intend.

In NServiceBus, we have three major means of telling NServiceBus to send a message:

  • Bus.Send
  • Bus.Reply
  • Bus.Publish

Each of these in turn corresponds to Commands, Replies, and Events, respectively. But we need to go one step further, and ensure that the names of our messages matches the intent of our communication. When names don’t match the semantics of an interaction, it’s a design smell and an indication that something in your design of interactions has gone awry.

One easy way to verify semantics is to simply check the naming of the message. Each message type has a very particular design in its name to be as explicit as possible about what the nature of the message and interaction is,

  • Command: Imperative verb
  • Reply: Noun
  • Event: Past-tense verb (past simple, to be specific)

Examples:

  • Command: RegisterCustomer
  • Reply: RegisterCustomerResult
  • Event: CustomerRegistered

Replies often describe the result of a command, and are usually tied 1:1 with a specific command. Or, a more general result can be used.

So if you Bus.Send a message that is worded in past tense, or Bus.Publish a message that seems rather bossy (Bus.Publish<UpdateCache>) then your interaction and semantics are off.

Next up – ownership.

Happy messaging!

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in NServiceBus. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1248

  • Pingback: Distributed Weekly 184 — Scott Banwart's Blog

  • http://gorodinski.com/ Lev Gorodinski

    What semantics do you use for queries? Something like: {Get}PreferredCustomers would be inline with the idea that queries are commands. Or, PreferredCustomers{Query} which would highlight the fact that it is a query, which can be an important distinction from what a command alone is.

    • jbogard

      Good question! I’ve gone back and forth on this myself. Sometimes I like GetPreferredCustomers, and other times PreferredCustomersQuery. I haven’t found one to be particularly better than the other, which probably explains my inability to just pick one over the other :)

      • http://gorodinski.com/ Lev Gorodinski

        Yeah, this is a tough one! I have been going with the query suffix to emphasize distinction from a traditional command which can have different processing characteristics – queries are rpc, commands can be async.

  • http://twitter.com/JamesRNail James Nail

    Jimmy, how about semantics for naming event handlers? Specifically, I’m thinking about handlers for cross-cutting concerns like security logging, change auditing, etc.

  • Pingback: Messaging Semantics: Ownership | Jimmy Bogard's Blog