Monthly Archives: September 2015

Introduction to CQRS and Event Sourcing – Part 2

Introduction,

In part 1 of this series, we had learned what CQRS is and what architecture style we can build just by applying this simple principle.

Before we dive into the code of simple domain problem, we need to learn few terms used in Domain Driven Design (DDD):

  • Domain: the business domain, which describes the problem that the solution is trying to solve.
  • Bounded Context: The term bounded context comes from Eric Evans’ book. In brief, Evans introduces this concept as a way to decompose a large, complex system into more manageable pieces; a large system is composed of multiple bounded contexts. Each bounded context is the context for its own self-contained domain model, and has its own ubiquitous language. You can also view a bounded context as an autonomous business component defining clear consistency boundaries: one bounded context typically communicates with another bounded context by raising events.
  • Context Map: According to Eric Evans, you should “Describe the points of contact between the models, outlining explicit translation for any communication and highlighting any sharing.” This exercise results in what is called a context map, which serves several purposes that include providing an overview of the whole system and helping people to understand the details of how different bounded contexts interact with each other
  • Aggregate: is a pattern in Domain-Driven Design. A DDD aggregate is a cluster of domain objects that can be treated as a single unit. An example may be an order and its line-items, these will be separate objects, but it’s useful to treat the order (together with its line items) as a single aggregate.
  • Aggregate Root: it is one of the aggregate component objects, where any reference from outside the aggregate should only go to the aggregate root. The root can thus ensure the integrity of the aggregate as whole.

Aggregates and Process Manager

In this sample, we’ll implement simple reservation process where the reservation consist of the following steps:

  • User picks number of seats to reserve and time of reservation.
  • Order is created with line items represent the seats to be reserved.
  • Seats reservation then check the availability of selected seats and then accept the reservation or reject it based on the availability.
  • The user gets the confirmation and asked for payment.
  • The user has to complete the payment within 10 minutes otherwise, the reservation will be canceled automatically.
  • Once the payment is completed, then the reservation is completed and the process ends.

The following diagram illustrates the aggregates and process manager for the selected process:


In the next part, we’ll have a look into the solution structure and the implementation details.

Preparing the development Environment


Introduction to CQRS and Event Sourcing – Part 1

Introduction,

CQRS stands for Command Query Responsibility Segregation, which means that methods of the backend are either a query or a command, where queries doesn’t change the state of the domain, while the commands change the state but doesn’t return results.

Originally, CQRS is not an architecture, it is a simple pattern that distinguish between methods that mutates state and methods that return values.

Having this simple principle, opens the doors for doing many interesting things that leads to different architectural styles, the largest benefit is that you recognize two different architectural properties when dealing with commands and queries… for instance, when you look into the load of your system most probably you will find that query part is taking most of the load while the write is minimal, so you take a step back and rethink again! Do I need to scale my services symmetrically in terms read and write operations? Will it be a waste of resources to not distinguish between my write services and read ones? If I have 8 servers does it make more sense to have 5 of them for read-only services and just 1 for write-only services?

Additional major concern comes to the table, is that do I need to have single model to serve both the read and write? What if my concern was to have very fast reading and I require to use different technology for that? Let say a sophisticated search engine like apache Solr, while I require a traditional RDBMS for the business domain itself!

By utilizing the Domain Driven Design principles and patterns, the architecture will evolve eventually into something similar to the diagram below:

In this blog series “Introduction to CQRS and Event Sourcing”, we’ll start by how we can implement such architecture using the following technologies and frameworks:


What is this blog about?

overview, , ,

Few years ago I started looking for distributed application framework in .NET, mainly for the purpose of building event driven systems, and exploring the use of Enterprise Service Bus.

 

During the journey, I found Masstransit, and there was a talk by Chris Patterson about Event Driven Architecture published here, and also I’ve explored the Domain Driven Design, and CQRS & Event Sourcing, and the Microsoft implementation CQRS Journey, and the open source NEventStore.

 

Greg young was the first one who I have learned from him, I have listened to all of his videos available commercially and on YouTube, they are awesome source of learning especially for whom don’t have any idea about the subject.

 

Due to the lack of available resources of complete systems, and the hard work it took from me to consolidate the samples from here and there to utilize the all of these technologies, concepts and framework, I decided to start this blog and publish the code of the blog series on GitHub.