CQRS Naming Conventions

Question

I'm implementing a new webservice and while I'm not yet using CQRS I would like to create my service so it could easily be moved to CQRS in the future. So, I'm wondering about naming convention for my DTO classes and also my methods.

I've read this blog post on DTO naming conventions and it seems sensible to me. It suggest the following ...

• SomeSortOfQueryResult
• SomeSortOfQueryParameter
• SomeSortOfCommand
• SomeSortOfConfigItem
• SomeSortOfSpecification
• SomeSortOfRow
• SomeSortOfItem (for a collection)
• SomeSortOfEvent
• SomeSortOfElement
• SomeSortOfMessage

What I'm asking here is how I should name my methods. Is it good practise to use GetSomething or would SomeQuery be better?

Answer 1

Naming should really just come out of the thing the method is doing. Take a step back and looking at Command-query separation (CQS) first. What you're really trying to do here is make sure that any given method is either querying for data or commanding that something happen.

I.e. "Asking for a value should not change the value".

CQRS is something different, on a larger scale, and generally less well understood. It's not necessarily complex, though, just applying the CQS concept at an architectural level rather than a code level. You might choose WCF for commands and raw SQL for queries, for example. It aims to allow you the freedom to make your queries the simplest thing that could possibly work, while your commands still get the richness of a full Domain Model or other suitable implementation for your business rules.

CQRS also steers you away from a CRUD application, to a task-based one where you focus more on the problem domain in terms of user interactions than just reading and saving data.

Queries

Generally I name "queries" variations on FindXYZ(), GetXYZ() or LoadXYZ, as long as the intent is clear (i.e. return some data, don't modify any).

Commands

Typically commands are harder to name, though you can think in similar terms to PowerShell's cmdlet naming conventions - verb-noun. Personally though I tend to implement commands as a CommandProcessor pattern, where commands are actually objects containing parameters (sometimes only a primary key of an entity). There is the code to look for appropriate "processors" for each command's Type. Typically in CQRS you'd try and keep this synchronous, because async means you have more work to do with respect to handling commands that failed to be processed, but if you really need a command to be async, then your command's handler might send a message to an ESB to do so.