Rethink your architecture with CQRS

Change the Rules Rethink you architecture with CQRS

Change the Rules Who are those guys? INTRODUCTION

Change the Rules

Change the Rules Agenda • Introduction • Current architectures & problems • CQRS • Food for thought

Change the Rules

Change the Rules Huidige architecturen bron: .NET Application Architecture Guide 2.0

Change the Rules Huidige architecturen Presentation layer Application layer Data layer

Change the Rules multi-tier Presentation layer Domain layer Data layer

Change the Rules Update DTO Presentation layer Request DTO Map DTO Domain layer Request Request DTO DTO Map DTO Map DTO Data layer Query data Query data Query data Query data

Change the Rules Update DTO Presentation layer Request Send DTO DTO Map DTO Map DTO Domain layer Request Request Send Send DTO DTO DTO DTO Map DTO Map DTO Map DTO Map DTO Data layer Query data Query data Query data Query data Write data Write data Write data Write data

Change the Rules “A single model cannot be appropriate for reporting, searching, and transactional behaviors.” – Greg Young

Change the Rules “Doordat software processen kan automatiseren stelt het ons in staat deze verder op te schalen dan ooit tevoren.“

Change the Rules “Every method should either be a command that performs an action, or a query that returns data to the caller, but not both.” – Bertrand Meyer

Change the Rules Presentation layer Domain layer Data layer

Change the Rules Presentation layer Data layer Domain layer

Change the Rules Presentation layer Read focus State transition focus Data layer Domain layer

Change the Rules Presentation layer Queries Commands Read focus State transition focus Data layer Domain layer

Change the Rules Presentation layer Queries Commands Read focus State transities focus Read layer Domain layer

Change the Rules Here we go! FROM CONCEPT TO ARCHITECTUUR

Change the Rules User interface

Change the Rules Queries • Requests information • Is context dependant • Is executed many times • Should be simple (select * from x where y) • Examples: – Get all products for user X – Get total price of all orders of month May

Change the Rules Read side User interface

Change the Rules Read side Read databases User interface

Change the Rules Read side Read databases Facade User interface

Change the Rules Read side Read databases Facade DTO’s User interface

Change the Rules Read side • Focus on data needs • Optimized for reading • Can contain multiple models if needed • Can be denormalized • Facades should be minimized

Change the Rules “State transitions are an important part of our problem space and should be modeled within our domain.” – Greg Young

Change the Rules Commands • Causes a state transition • Contains the intend of the user • Exists in a bounded context • Examples: – AddProductToShoppingCart – PurchaseOrder – MoveUserToNewAddress – CorrectAddressForUser

Change the Rules Commands example Create Remove Add item Add item Add item Purchase Cart item

Change the Rules Write side Read side Read databases Facade Commandhandlers commands DTO’s User interface

Change the Rules Command handler sample

Change the Rules The domain • Validates and handles commands • Encapsulates behavior • Build with rich object oriented techniques

Change the Rules Write side Read side Read databases Repository Domein Facade Commandhandlers commands DTO’s User interface

Change the Rules Write side Read side ? Read databases Repository Domein Facade Commandhandlers commands DTO’s User interface

Change the Rules Domain events • Result of a command • Represents a event • Examples – ProductAddedToShoppingCart – OrderPurchased – UserMovedToNewAddress – AddressCorrectedForUser

Change the Rules Transitional flow

Change the Rules Write side Read side ? Read databases Repository Domein Facade Commandhandlers commands DTO’s User interface

Change the Rules Write side Read side Denormalizers Event bus events events events Read databases Repository Domein Facade Commandhandlers commands DTO’s User interface

Change the Rules Denormalizer sample

Change the Rules Write side Read side Denormalizers Event bus events events events events Event store Read databases Repository Domein Facade Commandhandlers commands DTO’s User interface

Change the Rules Event store • Contains all domain events • Does not need to be relational • Contains the audit log • Read models can (re)build themself of it • The domain uses it to get the current state

Change the Rules Write side Read side Denormalizers Event bus events events events events queue Event store Read databases Repository Domein Facade Commandhandlers commands DTO’s User interface

Change the Rules Application flow

Change the Rules CQRS Wrapup • The domain receives commands and publishes domain events. • All state changes are represented by domain Events • The read models are updated as a result of the published Events • All Queries go directly to the read models, the domain model is not involved

Change the Rules Benefits • Fully encapsulated domain that only exposes behavior

Change the Rules Benefits • Fully encapsulated domain that only exposes behavior • Keep users intent

Change the Rules Benefits • Fully encapsulated domain that only exposes behavior • Keep users intent • Bullet-proof auditing and historical tracing

Change the Rules Benefits • Fully encapsulated domain that only exposes behavior • Keep users intent • Bullet-proof auditing and historical tracing • No object-relational impedance mismatch

Change the Rules Benefits • Fully encapsulated domain that only exposes behavior • Keep users intent • Bullet-proof auditing and historical tracing • No object-relational impedance mismatch • Optimized and multiple read models

Change the Rules Benefits • Fully encapsulated domain that only exposes behavior • Keep users intent • Bullet-proof auditing and historical tracing • No object-relational impedance mismatch • Optimized and multiple read models • Testability

Change the Rules Benefits • Fully encapsulated domain that only exposes behavior • Keep users intent • Bullet-proof auditing and historical tracing • No object-relational impedance mismatch • Optimized and multiple read models • Testability • Easy integration with external systems

Change the Rules Consequences • Learning curve • Overhead for simple CRUD • Data duplication • Introducing an new architecture has a big impact

Change the Rules Food for thought • Should your read model even contains a relational database? • What does this mean for requirement engineering? • What does this mean for outsourcing? • What does this mean for DBA?

Change the Rules You’ve been a great audience!

Change the Rules Reference material • Podcast with Greg Young • MyShop reference architecture • Ncqrs framework • InfoQ: Unshackle Your Domain

Rethink your architecture with CQRS

by Pieter Joost van de Sande on Apr 02, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 26

Statistics

Rethink your architecture with CQRS — Presentation Transcript