Don't know what CQRS is? You had better learn it fast.

CQRS stands for Command Query Responsibility Segregation. Its a simple concept that you can use a different model to persist information than the model you use to read information. This concept leads to some profound consequences for the design and scalability of systems.

CRUD is the mainstream approach people use for interacting with an information system datastore. By this I mean that we have a mental model of some record structure where we can create new records, read records, update existing records, and delete records when we're done with them. In the simplest case, our interactions are all about storing and retrieving these records.

As our needs become more sophisticated we steadily move away from that model. We may want to look at the information in a different way to the record store, perhaps collapsing multiple records into one, or forming virtual records by combining information for different places. On the update side we may find validation rules that only allow certain combinations of data to be stored, or may even infer data to be stored that's different from that we provide.

From Martin Fowler:
As this occurs we begin to see multiple representations of information. When users interact with the information they use various presentations of this information, each of which is a different representation. Developers typically build their own conceptual model which they use to manipulate the core elements of the model. If you're using a Domain Model, then this is usually the conceptual representation of the domain. You typically also make the persistent storage as close to the conceptual model as you can.

This structure of multiple layers of representation can get quite complicated, but when people do this they still resolve it down to a single conceptual representation which acts as a conceptual integration point between all the presentations.

The change that CQRS introduces is to split that conceptual model into separate models for update and display, which it refers to as Command and Query respectively following the vocabulary of CommandQuerySeparation. The rationale is that for many problems, particularly in more complicated domains, having the same conceptual model for commands and queries leads to a more complex model that does neither well.

By separate models we most commonly mean different object models, probably running in different logical processes, perhaps on separate hardware. A web example would see a user looking at a web page that's rendered using the query model. If they initiate a change that change is routed to the separate command model for processing, the resulting change is communicated to the query model to render the updated state.

There's room for considerable variation here. The in-memory models may share the same database, in which case the database acts as the communication between the two models. However they may also use separate databases, effectively making the query-side's database into a real-time ReportingDatabase. In this case there needs to be some communication mechanism between the two models or their databases.

The two models might not be separate object models, it could be that the same objects have different interfaces for their command side and their query side, rather like views in relational databases. But usually when I hear of CQRS, they are clearly separate models.

CQRS naturally fits with some other architectural patterns.
  • As we move away from a single representation that we interact with via CRUD, we can easily move to a task-based UI.
  • Interacting with the command-model naturally falls into commands or events, which meshes well with Event Sourcing.
  • Having separate models raises questions about how hard to keep those models consistent, which raises the likelihood of using eventual consistency.
  • For many domains, much of the logic is needed when you're updating, so it may make sense to use EagerReadDerivation to simplify your query-side models.
  • CQRS is suited to complex domains, the kind that also benefit from Domain-Driven Design.

When to use it

Like any pattern, CQRS is useful in some places, but not in others. Many systems do fit a CRUD mental model, and so should be done in that style. CQRS is a significant mental leap for all concerned, so shouldn't be tackled unless the benefit is worth the jump.

In particular CQRS should only be used on specific portions of a system (a Bounded Context in DDD lingo) and not the the system as a whole. In this way of thinking, each Bounded Context needs its own decisions on how it should be modeled.

So far I see benefits in two directions. Firstly is handling complexity - a complex domain may be easier to tackle by using CQRS. I do have to hedge this, usually there's enough overlap between the command and query sides that sharing a model is easier. Each domain has different characteristics.

The other main benefit is in handling high performance applications. CQRS allows you to separate the load from reads and writes allowing you to scale each independently. If your application sees a big disparity between reads and writes this is very handy. Even without that, you can apply different optimization strategies to the two sides. An example of this is using different database access techniques for read and update.

If your domain isn't suited to CQRS, but you have demanding queries that add complexity or performance problems, remember that you can still use a ReportingDatabase. CQRS uses a separate model for all queries. With a reporting database you still use your main system for most queries, but offload the more demanding ones to the reporting database.

It's also true that we haven't seen enough uses of CQRS in the field yet to be confident that we understand its pros and cons. So while CQRS is a pattern I'd certainly want in my toolbox, I wouldn't keep it at the top.

Persistent URL Proxy in C# MVC

I have quite a few websites, blogs and emails that contain links that frequently stale over time because I have a newer version of the document or I want the URL to point to some other resource.

Basically I want a 1 URL that doesn't change and I want to be able to change what that URL is actually pointing to.


In an email, I might have a link to a resume on Google Drive. Google Drive assigns a unique URL to my resume in WORD format when I share it. So now I have a URL pointing to my resume on Google Drive and it looks like this:

I can put that URL into my email and send the email out but what if I create a new file with updated resume information? Maybe I delete that file in my google drive and now anyone who clicks on the link to my resume will come to a resource not found.


Instead of making changes to "all" of the places that have the URL and re-publishing emails, blog posts, web content, I would prefer to just have a table of URL lookups in one place that's easy to update.

In order to solve this problem, I wanted to do something very quickly (like 5 minutes).  I don't want to pay for anything and I want to use resources I already have to put it in place.

With an existing website I operate,, I have created an MVC controller to handle my URL proxying.

My website:
Url to handle translations:[KEY]

Example: Url to handle translations:

On my google drive, I have a text file that is comma delimited name/value pairs which are line delimited by carriage return line feeds.

My google text file looks like this:


Then I create a controller to consume my URL lookup data and do the redirecting:

using System;
using System.Linq;
using System.Web.Mvc;

namespace MyControllers
    public class UrlProxyController : Controller
        public void UrlRedirector(string id)
            string fileStoreId = "[ID of Google Docs Text file data store]";
            string baseUrl = "";
            string urlStore = baseUrl + fileStoreId;
            var contents = new System.Net.WebClient().DownloadString(urlStore);

            string[] lines = contents.Split(new char[] {'\r', '\n' });
            string url = String.Empty;
            foreach (string s in lines)
                var keyValue = s.Split(',').ToList();
                string key = keyValue[0].ToString();

                if (key.Equals(id))
                    url = keyValue[1].ToString();

            if (String.IsNullOrEmpty(url))
                Response.Redirect("", true);
                Response.Redirect(url, true);

Now I want to modify my RouteConfig file because I want as short a URL as possible when using my PURLController action method. I am pretty certain I will never have a path that is named just "p" in my application so I will route all requests to "p" to my PURLController. Now my URL paths will look like this:

My website:
Url to handle translations:[KEY]

public class RouteConfig
        public static void RegisterRoutes(RouteCollection routes)

                name: "PurlRoute",
                url: "p/{id}",
                defaults: new { controller = "PURL", action = "Url", id = UrlParameter.Optional }

That is all she wrote. Now I can update URLs anytime easily from anywhere. You also can remove them to stale them or you can extend the functionality further by having a third item used to stale the redirect after a certain date time.

i.e. my text file would look like this

SomeIdorKey,,2015-12-01 11:59:12AM

Now when you consume this, check the date time value to see if the redirect is still valid otherwise redirect to some notification page saying the redirect is no longer valid.

Let me know if you have any questions.

Domain Driven Design and Bounded Context

Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD's strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.

DDD is about designing software based on models of the underlying domain. A model acts as a UbiquitousLanguage to help communication between software developers and domain experts. It also acts as the conceptual foundation for the design of the software itself - how it's broken down into objects or functions. To be effective, a model needs to unified - that is to be internally consistent so that there are no contradictions within it.

As you try to model a larger domain, it gets progressively harder to build a single unified model. Different groups of people will use subtly different vocabularies in different parts of a large organization. The precision of modeling rapidly runs into this, often to leading to a lot of confusion. Typically this confusion focuses on the central concepts of the domain. Early in my career I worked with a electricity utility - here the word "meter" meant subtly different things to different parts of the organization: was it the connection between the grid and a location, the grid and a customer, the physical meter itself (which could be replaced if faulty). These subtle polysemes could be smoothed over in conversation but not in the precise world of computers. Time and time again I see this confusion recur with polysemes like "Customer" and "Product".

In those younger days we were advised to build a unified model of the entire business, but DDD recognizes that we've learned that "total unification of the domain model for a large system will not be feasible or cost-effective" [1]. So instead DDD divides up a large system into Bounded Contexts, each of which can have a unified model - essentially a way of structuring MultipleCanonicalModels.
Bounded Contexts have both unrelated concepts (such as a support ticket only existing in a customer support context) but also share concepts (such as products and customers). Different contexts may have completely different models of common concepts with mechanisms to map between these polysemic concepts for integration. Several DDD patterns explore alternative relationships between contexts.

Various factors draw boundaries between contexts. Usually the dominant one is human culture, since models act as Ubiquitous Language, you need a different model when the language changes. You also find multiple contexts within the same domain context, such as the separation between in-memory and relational database models in a single application. This boundary is set by the different way we represent models.
DDD's strategic design goes on to describe a variety of ways that you have relationships between Bounded Contexts. It's usually worthwhile to depict these using a context map.

Further Reading

The canonical source for DDD is Eric Evans's book. It isn't the easiest read in the software literature, but it's one of those books that amply repays a substantial investment. Bounded Context opens part IV (Strategic Design).

Vaughn Vernon's Implementing Domain-Driven Design focuses on strategic design from the outset. Chapter 2 talks in detail about how a domain is divided into Bounded Contexts and Chapter 3 is the best source on drawing context maps.

The definition of multi-tenant data architecture

Multi-tenant data architecture

Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple tenants. A tenant is a group of users sharing the same view on the software they use. With a multitenant architecture, a software application is designed to provide every tenant a dedicated share of the instance including its data, configuration, user management, tenant individual functionality and non-functional properties. Multitenancy contrasts with multi-instance architectures where separate software instances operate on behalf of different tenants.

Commentators regard multitenancy as an important feature of cloud computing.

There are 3 approaches to multi-tenancy data design:

1) Storing tenant data in different databases.

2) Storing tenant data in the same database but different schemas.

3) Storing tenant data in the same database and same schema where data is keyed off of a unique tenant id.

What is reflection and what is its value?

Reflection provides objects (of type Type) that describe assemblies, modules and types. You can use reflection to dynamically create an instance of a type, bind the type to an existing object, or get the type from an existing object and invoke its methods or access its fields and properties. If you are using attributes in your code, reflection enables you to access them.

The main value of reflection is that it can be used to inspect assemblies, types, and members. It's a very powerful tool for determining the contents of an unknown assembly or object and can be used in a wide variety of cases.

Some useful applications:
  • Determining dependencies of an assembly
  • Locating types which conform to an interface, derive from a base / abstract class, and searching for members by attributes
  • Debugging - dumping out a list of the loaded assemblies, their references, current methods, etc.

What are dynamic objects?

Dynamic objects provide another way, other than the object type, to late bind to an object at run time. A dynamic object exposes members such as properties and methods at run time by using dynamic interfaces that are defined in the System.Dynamic namespace. You can use the classes in the System.Dynamic namespace to create objects that work with data structures that do not match a static type or format.

Dynamic objects also provide convenient access to dynamic languages such as IronPython and IronRuby. You can use a dynamic object to refer to a dynamic script that is interpreted at run time.

What are some restrictions to using yield?

  • A yield return statement can't be located in a try-catch block.
  • A yield return statement can be located in the try block of a try-finally statement.
  • A yield break statement can be located in a try block or a catch block but not a finally block.

Why is the Main() method static?

Static members are scoped to the class level (rather than the object level) and can thus be invoked without the need to first create a new class instance. The Main() method is static because it’s available to run when your program starts and as it is the entry point of the program, it runs without creating an instance of the class. In other words, static functions exist before a class is instantiated, so static is applied to the main entry point.

What is “DLL Hell”, and how does the GAC solve it?

“DLL Hell” describes the difficulty in managing versioning of dynamic linked libraries on a system. This includes multiple copies of a DLL, different versions, and so forth. When a DLL (or assembly) is loaded in .NET, it is loaded by name, version and certificate. The assembly contains all of this information via its metadata. The GAC provides the solution, as you can have multiple versions of a dll side-by-side.

What is a reason for having strings be immutable?

Strings will never get a race condition because of corruption. Immutable classes are easier to design, implement and use than mutable classes. They are less prone to error and are more secure. An immutable object can be in exactly one state, the state in which it was created.

What is upcasting and downcasting?

Downcasting refers to the process of casting an object of a base class type to a derived class type.

Upcasting converts an object of a specialized type to a more general type.

What does data or method hiding refer to?

Data or method hiding occurs when you create a method or data element in a derived class that replaces a base method or data element. This occurs when the new keyword is used to create the new method or method signature. It can also be referred to as shadowing.

Explain conditional operators?

The ?: operator is called the conditional operator. A conditional expression of the form b ? x : y first evaluates the condition b. Then, if b is true, x is evaluated and becomes the result of the operation. Otherwise, y is evaluated and becomes the result of the operation. A conditional expression never evaluates both x and y.

What is the difference between an Array and an ArrayList?

  • Arrays are strongly typed.
  • ArrayLists are not strongly typed.
  • Arrays are fixed length and cannot be resized dynamically during runtime.
  • ArrayList can resize dynamically during runtime.
  • Elements in an ArrayList can have a combination of combined data types or a single data type. 

Note: If an ArrayList has combined data types then a type cast is a must.

What is the difference between a parameter and an argument?

A parameter is a definition of what will be sent to a method. A parameter occurs within the definition of a method. An argument is a value that is passed to a method.

What is the difference between a class and a struct in C#?

Classes and structs are two of the basic constructs of the common type system in the .NET Framework. Each is essentially a data structure that encapsulates a set of data and behaviors that belong together as a logical unit. The data and behaviors are the members of the class or struct, and they include its methods, properties, and events, and so on, as listed later in this topic.

A class or struct declaration is like a blueprint that is used to create instances or objects at run time. If you define a class or struct called Person, Person is the name of the type. If you declare and initialize a variable p of type Person, p is said to be an object or instance of Person. Multiple instances of the same Person type can be created, and each instance can have different values in its properties and fields.

A class is a reference type. When an object of the class is created, the variable to which the object is assigned holds only a reference to that memory. When the object reference is assigned to a new variable, the new variable refers to the original object. Changes made through one variable are reflected in the other variable because they both refer to the same data.

A struct is a value type. When a struct is created, the variable to which the struct is assigned holds the struct's actual data. When the struct is assigned to a new variable, it is copied. The new variable and the original variable therefore contain two separate copies of the same data. Changes made to one copy do not affect the other copy.

In general, classes are used to model more complex behavior, or data that is intended to be modified after a class object is created. Structs are best suited for small data structures that contain primarily data that is not intended to be modified after the struct is created.

Classes Only:

  • Can support inheritance 
  • Are reference (pointer) types 
  • The reference can be null 
  • Have memory overhead per new instance 

Structs Only:

  • Cannot support inheritance 
  • Are value types 
  • Are passed by value (like integers) 
  • Cannot have a null reference (unless Nullable is used) 
  • Do not have a memory overhead per new instance - unless 'boxed'
  • Structs cannot contain explicit parameterless constructors. Struct members are automatically initialized to their default values. 

Both Classes and Structs:

  • Are compound data types typically used to contain a few variables that have some logical relationship 
  • Can contain methods and events 
  • Can support interfaces