Your SlideShare is downloading. ×
CQRS - Pittsburgh ALT.NET
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

CQRS - Pittsburgh ALT.NET

1,693

Published on

CQRS - Pittsburgh ALT.NET

CQRS - Pittsburgh ALT.NET

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,693
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
31
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Command-QueryResponsibility Separation (CQRS)
    Chris Geihsler
  • 2. Introduction
    About me
    Developing in .NET for 7 years
    Introduced to ALT.NET via Jeremy Miller’s blog
    Recently attended UdiDahan’s SOA course
    I’m not an expert on CQRS
    You won’t see much code
  • 3. Goals
    Introduce and discuss the information
    Identify strengths and weakness of the architecture
    Post any unanswered questions to the DDD discussion group
  • 4. UI
    Layered Architecture
    Services / Caching
    Weaknesses?
    Business Logic
    DAL
    Database
  • 11. Is there a better way?
    Reads and writes are different.
    Reads happen often and need to be fast
    Writes need to be transactional
    Architecture should reflect these differences.
    Separate read and write responsibilities.
  • 12. Reads (Queries)
    Create a model used only for reads
    Structure data around the UI
    One “table” per view
    Persistent View Model
    Inherently denormalized
    Read-only
    Data retrieval is easy and fast
    SELECT * FROM CustomerSummaryView
    Scales cheaply
  • 13. The world is not read-only
    The system needs to capture change
    Real world events
    User decisions
    Expose commands that change system state
    One-way
    Imperative
    Validated for correctness
  • 14. Writes (Commands)
    • Create a service layer that processes commands
    • 15. Keep it simple!
    • 16. Probably don’t need a domain model
    • 17. Create a data store that persists system state
    • 18. Transactional
    • 19. Write-Only (mostly)
    • 20. Single source of truth
  • Commands (cont.)
    • Write-only domain models are simpler
    • 21. No need for public getters or setters
    • 22. Example:
    public voidHandle(MakeCustomerPreferredCommandcmd)
    {
    using(ISessions = ORM.OpenSession())
    using(ITransactiontx = s.BeginTransaction())
    {
    varc= s.Get<Customer>(cmd.CustomerId);
    c.MakePreferred();
    tx.Commit();
    }
    }
  • 23. Closing the loop
    Command side publishes events
    Contain details about state change
    Past tense
    Query side subscribes to those events
    Updates persistent view models
    Consistency
    Immediate
    Eventual
  • 24. Event example
    public class CustomerWasMadePreferredEvent
    {
    public intCustomerId { get; set; }
    public decimal DiscountPercent { get; set; }
    }
    public void Handle(CustomerWasMadePreferredEventevt)
    {
    //UPDATE CustomerDetailsView WHERE CustomerID = evt.CustomerID
    //UPDATE CustomerSummaryViewWHERE CustomerID = evt.CustomerID
    //etc.
    }
  • 25. Questions?
  • 26. Further Implications
    Few relationships in either model
    Why use a RDBMS?
    Event sourcing
    Scalability via messaging patterns
    Events have other uses
    3rd Party Integration
    Real-time updates of clients
    CRUD based UI vs. Task based UI
  • 27. More Information
    Yahoo DDD discussion group
    http://tech.groups.yahoo.com/group/domaindrivendesign/
    UdiDahan’s website
    www.udidahan.com
    Greg Young
    Mark Nijhof
    http://elegantcode.com/author/mark-nijhof/

×