CQRS way

  • Typical architecture pros & cons
  • CQRS concept
  • Code example
    • Pros & cons






    Based on Greg Young's notes and OMD Vision, ADZU team 
    experience  

    Typical architecture

    • ORM (NH, EF)
    • MS SQL
    • DDD (Entity, Repository, Service)
    • WebApi CRUD (REST) services


    What the problem?





      Problems

      • You can’t do DDD
        • Anemic domain model
        • No aggregates
        • As result Business logic is blur (server, client, dev mind)
      • Lazy loading
      • Query optimization is punishment
        • One repository method for different reason
        • Leads to entity pollution
      • Data loss due to storing last state
      • Doesn’t scale
        • Very expensive horizontal scale, and limited vertical
      • Transaction and locks for readers

      Why do we use

      • Experience, it works at least
      • Devs understand it
      • Mature
        • You can google any problem
      • Tooling
      • Microsoft, Oracle propagation
        • They benefit from this architecture!
      • There isn't any other option
        • or is there?

      Free your mind

      • Save state vs history
      • We are lucky, CQRS started to live in .NET
      • Greg Young and Jonathan Oliver are fathers
      • CQRS completely different approach
        • With pros and cons, all about trade off
        • No silver bullet
      • Time for app to lose weight

      How?

      CQRS Concept

      Command Query Responsibility Segregation


      Concept


      Aggregate

      • Reply 
      • Snapshot

      Horizontal scale


      Advantages

      • Simplicity due to real DDD
        • Fast read (Thin read layer or SQLite, BerkeleyDB)
        • Flexible read optimization (MS SQL->Redis,ElasticSearch)
        • Time-travel (Reproduce bug)
        • Easy horizontal scaling
          • Read side scaling without limitation
          • Write side is scaled  by sharding  ToMD5(id) % 10 + 1 // 1..10
          • Across data centers, node on demand
        • No data loss due to storing all events
          • Audit, big data ready (forecast, fraud detection, debug)
          • Sophisticated reporting
            • Users who created >10 companies per month during 3 month at 2012; Activity stream
        • Integration for free due to event sourcing

        Disadvantages

        • Hard to understand at the beginning (eventual vs transactional consistency)
        • Feature implementation takes more time
          • Extra code should be written (command, event, projection)
        • Fit for system with <30% writes
        • Hot fixes slower, no possibility to run SQL to fix
        • Long projection rebuild (in-mem, background, rebuild changed)
        • Read side lag (due to eventual consistency)
        • Painful aggregate refactoring

        CQRS code examples:

        • Controller write
        • Command
        • Command handler
        • Aggregate
        • Event
        • Projection
        • Controller read
        • Write database

        Controller write



        Command

        Command handler

        Aggregate

        Event

        Projection


        Controller read

        Write database

        Questions


        CQRS overview (rev 2)

        By Vladimir Gaevoy

        CQRS overview (rev 2)

        • 2,079