Cqrs makes the web project much easier. On the get site, all the queries will look like "select * from table where id = @id"). For those simple queries, you won t need an orm like NHiberante. You don t have to use a sql database, and when you will, you can serialize your object to the database table, or use a naming convention. You can still query the read database by NHibernate, but you won t get any advantage from it, because all your queries will be the same.

public class Controller
{
  public ActionResult Get(Guid id)
  {
     var viewModel = reportingDatabase.Get(id);
     return View(viewmodel);
  }
}

On the command side, the controllers will look like this:

public class Controller
{
  public ActionResult Post(SomeForm form)
  {
    // do validation
    var command = new SomeCommand(form.Property1, form.Property2);
    bus.Send(command);
    return redirecto(something else);
  }
}

The controller just send a message, and it doesn t know where the message goes to and what the result of the message is. The mvc part of this is very simple to program. Cqrs will make writing the web-part of the application very boring, but you can make it more fun by adding some code that helps the user make decisions (optionally returning json used by ajax).

Please take a look at my DDDsample.Net project on CodePlex. The GUI is implemented using ASP.NET MVC while the business logic using DDD practices in 4 different variants:

• classic (no CQRS)
• CQRS with two NHIbernate relational data stores
• CQRS with LINQ to SQL on reporting side
• CQRS with Event Sourcing on command side

And take a look at my attempt at http://agrcqrs.codeplex.com, which is ASP.NET MVC + NHibernate

Here is a complete example I wrote for my CQRS lib Scritchy:

• Example.Domain: Domain implementation
• Example.Specs : Domain behavior specs using MSpec
• Example.Web : Example MVC web app (demo at http://scritchyExample.apphb.com )
• Example.SignalR : Example html/Javascript/SignalR web app (using the same domain code)

Creating your CQRS app using the Scritchy nuget package is pretty straightforward and gets you up and running in a few minutes

In the following post you may find interesting resources: How to adapt CQRS to projects

The one that I found particularly interesting is the CQRS Journey, from Microsoft. It may look disappointing for its dependency with Windows Azure, but wait... It has a very nice implementation of an Event Store and Enterprise Service Bus in SQL Server. You will find a lot of comments in the Demo App source code that warns you against using the SQL implementation in production... but with a few tweaks you can adapt it to your project. I did it, and it works very, very well.

The code is clean (it is from the guys from Microsoft Patterns and practices). You will find a good example of how to use dependency injection (with Unity), an simple but effective Enterprise Service Bus (with SQL Server and ADO.NET, with parallel threads), a read model with Entity Framework and a lot more. I learned from it how to do CQRS and Event Sourcing... Remember: Its all about Events

This is a bit of a late response, yet it might be helpful for someone who is looking how to implement CQRS architectural pattern in ASP.NET Core and surprisingly didn t find any proper middleware for that matter. During my discovery process, I decided to share my findings and ended up writing a series of articles on how to do CQRS via HTTP.

1. CQRS: Intro
2. CQRS: Commanding via HTTP
3. CQRS: Querying via HTTP

Apart from the theoretical aspect, during the writing process, I managed to build two ready-to-use, independent middleware that are built to help you adopt CQRS in your ASP NET Core project. HTTP Commanding and HTTP Querying.

Hope it helps, if you have any questions, don t hesitate and shoot me a message.