CQRS Naming Conventions

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 i开发者_如何转开发s how I should name my methods. Is it good practise to use GetSomething or would SomeQuery be better?

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.

Talking about DTOs in the context of CQRS rings alarm bells for me where you are specifically talking about the query side. Quoting that blog article

the DTO (Data Transfer Object) pattern was originally created for serializing and transmitting objects

A CQRS architecture implies a thin query side to me i.e. you don't have lots of layers where you need to move information between them with serialized objects or DTOs. It might be that you're using the term DTO in a different sense.

That doesn't really answer your question but I wanted to point it out.