Microservice Architecture with CQRS and Event Sourcing

Microservice Architecture with CQRS and Event Sourcing

• 1.
  Microservice Architecture with CQRS &Event Sourcing Ben Wilcock Freelance Software Architect [UK] https://twitter.com/benbravo73 https://www.linkedin.com/in/benwilcock http://benwilcock.wordpress.com
• 2.
  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)
• 3.
  What is EventSourcing (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
• 4.
  What are thePrinciples 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 well A philosophy at the heart of UNIX development that leads to small and highly-cohesive applications Event-Driven Architecture Also 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-coupling An approach to interconnecting components such that those components depend on each other to the least extent practicable Event sourcing A mechanism for persisting application's state by storing the history of events or changes that caused the system to arrive at its current state
• 5.
  What are theBenefits 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
• 6.
  What are theBenefits 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
• 7.
  What does CQRS/ESArchitecture 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
• 8.
  Why choose CQRS/ESfor 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
• 9.
  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
• 10.
  An Industry Perspectiveon 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...
• 11.
  Hungry for more? Checkout 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 Wilcock Freelance Software Architect [UK] https://twitter.com/benbravo73 https://www.linkedin.com/in/benwilcock http://benwilcock.wordpress.com