How to Read and Write using CQS

Question

I'm going to start off a new project with CQS (as one aspect of its design), but NO CQRS + Event Sourcing, or Event Streaming, or Historical Modeling. When I come across a situation in which I will have a large set of people using a small set of data (and do not want to block the user), I will implement Event Sourcing. What this means (to me at least) is all I’m doing is starting out with a separation of the command from query (separation of concerns).

I'm using EF ORM and the actual Schema for the command side. On the query side it's best to use only views (from what I'm reading), but this opinion I think doesn't preclude me using an ORM (or not), and/or Repo, or ADO.NET + Stored Procedures, etc., as method for accessing these views from the DB (I think).

Here is a diagram I made to approximately-illustrate what I have in mind (its by no means comprehensive):

My question:

Part 1: I don't know the -- right /best/easiest/most optimized/most maintainable/easiest to migrate to event sourcing at some point -- way (I realize this is subjective) to retrieve data from the database (from a View) and use ViewModels (DTOs) to supply the client a fresh view of some state (AFTER a call to the command side)?

Part 2: After I've made a change to the task based web UI, and therefore changed ViewModel that underlies the UI, how do I issue a Command from this when the ViewModel is completely separate from Entities (Domain Model) on the command side. These ViewModels (DTOs) might be a completely different "shape" than the Entities.

UPDATE:

To be clear, I'm not going to use Async and Transactions are a plus to start, this is only Command and Query Separation (not full blown CQRS, where the Command side returns "void" only) -- I'm looking for the very basics here. Also, from what I've read so far, it seems DDD and the Bounded Context go hand in hand with CQRS, at this point I have no real experience with DDD or Aggregate Root along with the Bounded Context and so far have not seen a real and pressing need to engage with this methodology/pattern. At this moment it seems I will be using EF/Migrations for the Command side, and have not decided what to use on the Query side (ADO.NET is being considered).

The Command side in my case will return an object, for example a new Customer with a database generated CustomerId. I will use one database for both Commands and Queries, and would like to use Views build in the DB for as return Models from the Queries (in other words, I would like the Queries to be "mapped" to Views for the most part). What I don't know is how the Command should look in cases where and object should be returned, if I'm to use the Query side to return data for the Command side. I'll try to incorporate Automapper to convert the objects to ViewModels in the case of MVC.

Answer 1

I must admit I am having a hard time trying to find the actual question here, but i'll go with the title as the basis for my answer.

First of all you're stating that you're not going to to use CQRS, but your proposed solution is very close to a CQRS architecture, more so than anything else. Being a beginner and trying out a pattern but at the same time modifying it heavily is adding a high degree of complexity.

Basically for being able to read and write successfully using CQS it is important that the caller has control of the generation of Id's. This lets you save an object and then later retrieve it without having to rely on the command operation returning values. Guids are excellent candidates for this.

Also i should state that there are very big differences between CQS and CQRS as patterns. CQS is a low level pattern that you can apply within pretty much any architecture, while CQRS is very high level pattern. They share the design philosophy but not much else.