Naming should really just go beyond what this method does. Take a step back and first look at Command Query Separation (CQS) . What you're really trying to do here is to make sure that any given method either requests data or commands that something happens.
those. "A value request should not change a value."
CQRS is something else, on a broader scale and, as a rule, less understood. However, this is not necessarily complicated by simply applying the CQS concept at the architectural level rather than the code level. For example, you can choose WCF for commands and raw SQL for queries. It aims to provide you with the opportunity to make your queries the simplest thing that could work, while your teams still get the wealth of a complete domain model or other suitable implementation for your business rules.
CQRS also takes you away from a CRUD application to a task-based facility where you pay more attention to a problem domain in terms of user interaction than just reading and saving data.
Inquiries
As a rule, I call the "query" options on FindXYZ() , GetXYZ() or LoadXYZ if the intention is clear (that is, return some data, do not change ).
Teams
Commands are generally more difficult to name, although you may think in similar expressions with PowerShell cmdlet naming conventions - verb-noun . Personally, although I tend to implement commands as a CommandProcessor template, where in fact the commands are objects that contain parameters (sometimes only the primary key of the object). Then there is code to search for the corresponding "processors" for each Type command. Typically, in CQRS you try to keep this synchronous, because async means that you have more work dealing with processing commands that have not been processed, but if you really need a command for async, then your command handler can send an ESB message for this.
cqrsinfo.org is a good place to find more information.