Domain CQRS Blog

CQRS

CQRS stands for Command Query Response Segregation. Coined by Greg Young it is an extension of CQS (Command Query Seperation) and takes it a step further by having commands and queries handled by separate objects.

Commands affects the state of an entity and don't return anything.  Queries return the state of the entity without affecting the state.

 CQRS is not an architecture, it is a pattern.  It can be applied to the whole of an application or just a part, it could even be applied to just a single layer or a vertical slice of an application. It can allow for the architecture of the Command side to be completely different to the Query side.

• Udi Dahan on CQRS Clarified
• Greg Young on What is/is not CQRS
• Martin Fowler on CQRS
• Intro to CQRS on CodeProject
• MSDNs CQRS Journey

Event Sourcing

Event Sourcing is a method of entity storing, it works particularly well on the Command-side when employing CQRS.  When a command arrives for an entity all previous events for the entity are loaded and applied in order, these historical events brings the entity back the last state it was in.  This is different to an O/R Mapper that would have saved and loaded the state directly. The command is then applied to the entity and the resulting events are then stored.

The drawback of Event Sourcing is that querying based on attributes of the current state is very inefficient, but it leads to a strength when applying the CQRS pattern.  Events can be processed after they have been stored, they can be projected into read models that are exactly what is needed on the query side.  Events can be projected in multiple ways to satisfy each individual query, eg. only the required fields and pre-sorted in the required order.

Replaying events from the beginning can also be used to re-generate the read model from scratch, or create completely new read models if needed.

• Greg Young on Why use Event Sourcing?
• Rinat Abdullin on Why Event Sourcing?
• Martin Fowler on Event Sourcing

Domain Driven Design

Described by Eric Evans in the "blue book", it is a method of designing applications where Domain Experts take centre-stage to develop a Ubiquitous Language, Bounded Contexts and Aggregate Roots.

DDD concentrates on delivering a fully-fleshed domain model such that applications take on a concentrically layered form with the domain layer at the centre, like an onion. The storage, service and user interface layers can then surround the domain layer.

• DDD Step-By-Step Guide
• Martin Fowler on the DDD anti-pattern Anaemic Domain Model
• Jeffrey Palermo on Onion Architecture

Behaviour Driven Development

Test Driven Development as an Agile methodology has been around for a while, but it does suffer from a "where do I start?" problem.  The idea of BDD is that you start with stories developed with stakeholders that then can be used to produce scenarios that can be tested.

Stories are written using 

• In order to...achieve some aim
  
• As a...stakeholder
  
•  I want to...take some actions

Scenarios for a Story are then written using

• Given...some existing events occurred
• When..some new events happen
• Then...this is the outcome expected

BDD works very well when testing the Domain Model of a  CQRS+Event Sourcing application.

• Dan North Introducing BDD
• Liz Keogh - They're Not User Stories