MicroserviceArchitecturewith CQRS & Event Sourcing

Ben WilcockFreelance Software Architect [UK]https://twitter.com/benbravo73

https://www.linkedin.com/in/benwilcock http://benwilcock.wordpress.com

What is CQRS?

2

‘Command & Query Responsibility Segregation’

CQRS is an architectural pattern for developing software whereby the bits of the system that are responsible for changing

the system’s state (the ‘write-parts’) are physically separated from the bits of the system that manage views (the ‘read-parts’)

This is in contrast to CRUD architecture where traditionally the same component has responsibility for both the reads (the

views) and the writes (the state changes)

What is Event Sourcing (ES)?

3

Event Sourcing uses a timeline to describe state

When Event Sourcing, state is recorded as a complete series of the events resulting from the actions taken within the domain

These persisted events can then be used to re-establish the state of the actors within the domain at any point in time

This is in contrast to CRUD architecture where traditionally only the current state of an entity is stored (and not the history of

events describing how it arrived at this current state)

Event sourcing complements CQRS, but CQRS does not require event-sourcing in order to be successful

What are the Principles behind CQRS/ES?

Separation of Concerns (SoC)A design principle for separating a

computer program into distinct sections, such that each section

addresses a separate concern

Do one thing and do it wellA philosophy at the heart of UNIX

development that leads to small and highly-cohesive applications

Event-Driven ArchitectureAlso known as Message-driven architecture, this is a software

architecture pattern that promotes the production, detection,

consumption and reaction to events over other forms of integration

4

Domain-Driven Design (DDD) A software development approach

whereby the implementation is strongly linked to the business

domain in which it’s used

Loose-couplingAn approach to interconnecting

components such that those components depend on each other to

the least extent practicable

Event sourcingA mechanism for persisting

application's state by storing the history of events or changes that caused the system to arrive at its

current state

What are the Benefits of CQRS?

Scalability

In mosts systems the number of reads vastly exceeds writes - yet the architecture

rarely reflects this

In CQRS the read-side is separate from the write-side, so each can be scaled and

performance-optimised independently

Simplicity

In most systems a single model is used to manage, describe, store and view data

This sounds simple, but it adds complexity as contradicting requirements (writing and reading) must be handled by a single model

With CQRS the write-model and the read-model can be different

Flexibility

The clear separation of methods that change state from the methods that view

state makes change simpler

Change can be made with greater confidence and with more predictable

effects

Business Focus

Commands are intuitive and instantly recognisable as business related actions

In CQRS this business focus together with Domain Driven Design can result in

applications that are more responsive to change and cheaper to maintain

5

What are the Benefits of Event Sourcing?

History has Business Value

By storing events, you never discard information that may have future value

Events allow you to see the state of the system at any point in the past

You can use this insight to answer historical business questions as they arise

Easy Integration

Events are also a useful way of communicating with other systems

Integration based on events offers very low levels of coupling as the event producers

don’t need to know anything about the event consumers (and vice versa)

Simplicity

By saving only events, you are avoiding the complex business of persisting complex

domain objects to a relational store - otherwise known as the “object-relational

impedance mismatch”

Performance

Events are simple, standalone and immutable, so you can use faster append-

only operations to store them

Flexibility

A sequence of events can be "projected" into any desired structural representation or

"view" at any time

6

What does CQRS/ES Architecture look like?

Multiple views or ‘projections’ can be built to

satisfy disparate

client requirements & limitations

Integrations are unlimited, event-based and loosely-coupled

Interactions are modeled as

simple ‘Commands’, ‘Events’ and ‘Queries’

Events are stored and

then forwarded to the event exchange

command-side(Rules and Behavior)

query-side(Presentation and Facts)

7

Read-side can be scaled,

optimised and secured

independently of the Write-

side

Command processing results in

Events being created

Why choose CQRS/ES for your architecture?

Here are my Top 5 reasons to consider CQRS/ES for your architecture

1. The number of reads, queries and views usually far exceeds the number of writes, so a separation of these concerns can make development simpler and faster

2. Events are ubiquitous; every business process has them, so modelling systems on events and storing past events has real business value

3. Often when choosing CRUD architecture, we under-estimate the complexity of the logic required to manage the life-cycle of our business entities - this has major impacts later, particularly on scalability

4. Event-based integration is far easier to manage and maintain than traditional ‘canonical model’ based integration techniques

5. Having independent data projections and views is really useful, particularly if you have multiple disparate clients that require access to similar information - such as mobile, web, public api’s etc.

8

Who uses CQRS & Event Sourcing?

The CQRS / ES approach to application architecture works well with Microservices, so it’s popular with organisations that need cost effective scaling, organisations like...

9

An Industry Perspective on CQRS/ES

10

CQRS [Axon] - ASSESS

CQRS can work very well in specific places. In those specific situations, however, a lot of work is left to the developer to properly execute CQRS.

Axon is a framework that can help with this on the JVM, and we’ve used it with some success.

Although it’s not perfect, it continues to evolve and may make much more sense than trying to write everything from scratch.

My Axon Sample: https://goo.gl/uGGISx

Event Sourcing - TRIAL

Event Sourcing ensures that all changes to application state are stored as a sequence of events.

Complementary to the capture of meaningful business events, the technique has positive implications for analytics in driving greater customer insight.

Not only can we query events, we can also use the event log as history, and as a foundation to automatically adjust the state to cope with retroactive changes.

CQRS/ES is still considered a new and innovative approach to software design. Here’s what ThoughtWorks said about CQRS and Event Sourcing in their 2015 Tech Radar...

Hungry for more?Check out my Axon based CQRS/ES

Microservice sample code on GitHub: https://goo.gl/uGGISx

For a conversation about how I could help your team to achieve great things, contact me using

the social media links below:

11

Ben WilcockFreelance Software Architect [UK]

https://twitter.com/benbravo73 https://www.linkedin.com/in/benwilcock

http://benwilcock.wordpress.com