Successfully reported this slideshow.
Your SlideShare is downloading. ×

CQRS for human beings

CQRS for human beings

  1. 1. 🔑 🔑
  2. 2. 🔑 🔑
  3. 3. 🔑 🔑 🔑 🔑
  4. 4. • • • •
  5. 5. • • •
  6. 6. •State: NotRunning •Title: “” •StartDate: null •SignedCount: 0 •Singers: [] •FinishDate: null PetitionStarted •State: Running •Title: “My new petition” •StartDate: 08/05/2018 SignerAdded •Singers: [“Todor Todorov”] SignerCountChanged •SignedCount: 1 PetitionFinished •State: Finished •Title: “My new petition” •StartDate: 08/05/2018 •SignedCount: 1 •Singers: [“Todor Todorov”] •FinishDate: 09/05/2018
  7. 7. • • • •
  8. 8. • • • •
  9. 9. • • • • • •

Editor's Notes

  • Introduce yourself
    1 year with CQRS and Event Sourcing
    Passion about CQRS

    I will guide you through the evolution of our software.
    Because to me, CQRS is the natural evolution step in enterprise software development.
  • Ask questions you might forget
    Give feedback
    Vote in the poll
    Get the presentation
  • Document management system – Monolith
    Client wanted a workflow engine
    Execute business processes over documents
    Storing a document triggers a workflow (INSTANCES)
    Indexing is applied
    Users get tasks
    Users confirm decisions
    Workflow ends

    Q: How many monoliths here?
  • A trivial CRUD system
    Instances are created
    Tasks deleted after confirmation
    Instances are deleted after finish
    Small DB = Fast requests
    Client wanted History
    Missing History
    We could do one thing

  • Great developers
    Did it by the books
    PO had to think of this

  • Stop deleting anything
    Add state column
    Get History from here
    Client wants History of automatic steps
  • 1. PO is to blame again
  • Added History tables
    Move from active to History
    Data = Text for UI
    Customer got a corrupted workflow.
    Asked to restore it from history
    Can’t, history is only for UI
  • Getting in the cloud
    GetTasks – SLOW
    Scaling – Not very efficient

    Q: Anyone had such problems?
    Q: How did you solve it?
  • Colleague said CQRS is awesome
    Skeptic at first
    Many discussions
    Changing architecture is hard
    But first – WHAT IS CQRS?
    It is not scary!
  • OK, it is scary!
    That makes you cringe
    Let’s simplify
  • Not so scary now
    Makes sense
    WHY do we need that?
    Did a research
    We read more than we write
  • Our logs show that

    Q: Have you done such a check?
    Q: What does it show?

  • Started thinking about separation
    How do you separate your model?
    Makes a lot of sense
    Many things – not used in both
    Colleague afraid to have much data in table
    Told him because he haven’t split
  • Read site (query model)
    Queries return data
    Write side (command model)
    Commands mutate state
    Async – Not mandatory
    But preferable
  • Scale Read & Write independently
    Read side denormalized
    Read side straightforward
    Write side is not UI dependent
    Model separation is meaningful
    Scales better
  • CAP Theorem
    Eric Brewer
    You need to duplicate data in models quite often
  • State is stored as a series of events
    Append only store
    Compares to transactional log of DB
    Entities are called Aggregates
  • Start by initial instance
    Apply events one by one
    Each event changes specific properties
    Idempotent events
    Applied events go to Projections (ReadModels)
  • Concerned about size
    How to iterate millions of events
  • If you use SQL – it is FAST
    Good PK = FAST
    Snapshotting = aggregate state every 5-10 events
    Small DB footprint with Google Protobuf
    At time of choice – best serialization
  • Made Get tasks faster
    Most important about client
    Confirms are async in the background
    How fast?
  • Can you guess how much
  • Independently scale
    Split models = clear models
    GetTasks got a lot faster
    Create Read Models Easy
    Fancy words on our resume and site
    That was a joke…

    No it’s not (DO NOT READ)
  • In my blog
    In Slido