CQRS without Multiple Data Sources

One of the most common misconceptions about CQRS is it implies Eventual Consistency. That you must have different data sources for your commands and queries. Meaning you will have a use one data source for commands/writes and an entirely different data source for query/reads. This is simply untrue.

This assumption implies that you’re query/read data source will be eventually consistent with the command/write side. This is because the assumption is your commands will write to its data source, then emit events that will be processed and update your query/read database independently.

If you’re unfamiliar with CQRS, I highly recommend checking some other posts I’ve written about CQRS before reading futher.

Different Models

One of the benefits of applying CQRS is that you can have different representations of your data. Your write model may look very different than your read model.

However, this doesn’t mean you need to have different data sources and use event handlers to build your query model.


If you’re just getting into applying CQRS, you can use the exact same underlying data model for both commands/writes and queries/reads. There’s nothing saying you can’t.

However, if you’re using a relational database you can get all the benefits of tailored query models by mapping your queries/reads models to database views. Or if you database supports it, materialized views.

If you’re using Entity Framework Core, this is pretty straight forward by defining your query types in the OnModelCreating method of your DbContext.


This means you’re command/write model and query/read models are always 100% consistent. You’re not dealing with eventual consistency.

Another bonus is you’re not writing event handlers to update your read/query database which also eliminates a pile of code and complexity.

From my experience, when applied wrong, eventual consistency can be a giant pain and not at all what you’re users are expecting.

Most often users are expecting to click a button and see the results immediately. Obviously, there are many ways to handle this, but if you’re new to CQRS, my initial recommendation is to keep things as simple as possible and that means keeping data consistent.

Start simple:

  • Create a class that changes state (command) and create a separate class that reads state (queries).
  • Use SQL Views (or materialized views) to map tailored queries.
  • Use something like Automapper for compositing the query result.


If using Views isn’t an option, and you’re using the same relational database for both reads and writes another option is to wrap the entire operation in a transaction. This means your operation to modify your database records for the command, as well as modify database records for your queries happen within the same transaction.

I’ll elaborate more on this, eventual consistency, event sourcing and more in coming posts.

Fat Controller CQRS Diet

I’ve blogged a bit about how to implement CQRS without any of the other fluff. You can check out my Fat Controller CQRS Diet blog series as well as a related talk:

If you have any questions or comments, please let me know on twitter as I will focus my posts on those questions and comments.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #39: Performance Tricks, Orleans Dashboard, ASP.NET Tips, Six Little Lines of Fail

Here are the things that caught my eye this week in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

Some performance tricks with .NET strings

I’ve created a pull request on the ASP.NET Core repository. At the beginning, the changes were just about changing the unsafe code (char*) for stackalloc to a safe version with Span<T>. So, it was a very small change. During the review, Oleksandr KolomiietsGünther Foidl, and David Fowler have suggested a few additional changes to improve the performance. Thank you very much for taking the time to review the PR! The comments were very interesting, so I’ve decided to explain them in a post.

Link: https://www.meziantou.net/2019/03/04/some-performance-tricks-with-net-strings

Microsoft Orleans   Dashboard

Quick update to a post I did a while back regarding Orleans Dashboard — additional reporting metrics for your cluster!

As a refresher, Orleans is a virtual actor model framework — a framework that can be used to build new, distributed “primitives”. These primitives’ work can be farmed out to a cluster of nodes as a means of getting “work” done faster than what would be possible if working constrained to a single piece of hardware.

Link: https://hackernoon.com/microsoft-orleans-dashboard-update-cpu-memory-stats-706daed82cf8

Tips and tricks for ASP.NET Core applications

This is a small collection of some tips and tricks which I keep repeating myself in every ASP.NET Core application. There’s nothing ground breaking in this list, but some general advice and minor tricks which I have picked up over the course of several real world applications.

Link: https://dusted.codes/advanced-tips-and-tricks-for-aspnet-core-applications

Six Little Lines of Fail – Jimmy Bogard

It seemed like an easy feature to implement, a checkout page to place an order. But this payment gateway has a simple API, so we added that. And this email service provider makes it possible to send an email with one line of code! Finally we can notify downstream systems via a message queue. The code looks simple, 6 little lines of distributed systems code.

But those lines hid a dark secret that we only found after launching. Customers complained they didn’t get their email. The back end system wasn’t getting updated from our messages. And by far the worst of all, customers complained they saw an error page but still got charged!

Clearly it wasn’t as easy as calling a few APIs and shipping, we actually need to worry about those other systems. In this session, we’ll look at taking our 6 lines of distributed systems fail, examining the inevitable failures that arise, and possible mitigating scenarios. We’ll also look at the coupling our code contains, and the ways we can address it. Finally, we’ll refactor towards a truly resilient checkout process that embraces, instead of ignoring, the fallacies of distributed computing.

Link: https://www.youtube.com/watch?v=LGG3IIHUG_w

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #38: Port Desktop App to .NET Core 3, Building 300+ csproj, .NET Core 3 Progress, Four Languages from Forty Years Ago

Here are the things that caught my eye this week in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

How to port desktop applications to .NET Core 3.0

In this post, I will describe how to port a desktop application from .NET Framework to .NET Core. I picked a WinForms application as an example. Steps for WPF application are similar and I’ll describe what needs to be done different for WPF as we go. I will also show how you can keep using the WinForms designer in Visual Studio even though it is under development and is not yet available for .NET Core projects.

Link: https://devblogs.microsoft.com/dotnet/how-to-port-desktop-applications-to-net-core-3-0/

How do you all build really large .NET repos (like more than 300 .csproj)?

This is a really interesting thread. I can’t imagine building 300+ projects. I currently have a solution with just around 50 and I’m always trying to reduce it. What type of projects are people working that require 300+ projects?

Link: https://twitter.com/natemcmaster/status/1099021447920406529

.NET Core 3.0 Progress on Bugs

Link: https://twitter.com/ziki_cz/status/1100865306484850688

Four Languages from Forty Years Ago – Scott Wlaschin

The 1970’s were a golden age for new programming languages, but do they have any relevance to programming today? Can we still learn from them?

In this talk, we’ll look at four languages designed over forty years ago — SQL, Prolog, ML, and Smalltalk — and discuss their philosophy and approach to programming, which is very different from most popular languages today.

We’ll come away with some practical principles that are still very applicable to modern development. And you might discover your new favorite programming paradigm!

Link: https://www.youtube.com/watch?v=0fpDlAEQio4

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.