Your SlideShare is downloading. ×
0
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
Practical Domain Driven Design, CQRS and Messaging Architectures
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

Practical Domain Driven Design, CQRS and Messaging Architectures

10,126

Published on

An expanded version of my previous presentation on DDD, this version was presented at the Sydney Architecture User Group, Thursday 27/05/2010, 6:00 PM, Grace Hotel , Kiralee or Pinaroo Function Room …

An expanded version of my previous presentation on DDD, this version was presented at the Sydney Architecture User Group, Thursday 27/05/2010, 6:00 PM, Grace Hotel , Kiralee or Pinaroo Function Room 77 York St Sydney, NSW. 2000

Published in: Technology
0 Comments
40 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
10,126
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
410
Comments
0
Likes
40
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. Jak Charlton
    jak@thinkddd.com
    www.thinkddd.com
    Readify
    www.readify.net
  • 2. Practical Domain Driven Design
    Message Based Architecture and CQRS
  • 3. Domain Driven Design IS
    An architectural methodology
    for evolving a software system
    that closely aligns
    to business requirements
  • 4. Domain Driven Design IS NOT
    A silver bullet
    A panacea for all your troubles
    An easy path to follow
    Always the best solution
    And most importantly, it is not focused on the How, but the What and Why
  • 5. Where Are We Going?
  • 6. The Domain Vision Statement
    A shared understanding of what it is you are actually trying to create
    Should be brief, written in clear English and understood by business and tech people alike
    Should be factual, realistic, honest
    Should avoid superlatives and marketing speak
    Should avoid technical and implementation details
  • 7. Domain = Sphere of Activity?
  • 8. Domain
    A Domain is a Sphere of Knowledge, Influenceor Activity
    A Domain is represented by the Ubiquitous Language
    A Domain encapsulates a Domain Model
    A Domain lives within a Bounded Context
  • 9.
  • 10. The Ubiquitous Language
    Human languages are Lossy Abstractions
    A major reason for failure of software projects is a failure of people, the failure to communicate
    The Ubiquitous Language is a shared language between the business and the development teams
    The UL comes from the business, and is enriched by the development teams
  • 11.
  • 12. Domain Experts
    Domain Experts are the primary point of contact the development teams have with the business
    They are the Experts on their part of the business, not just users of the system
    They should have deep knowledge of the subject Domain
  • 13. Looks Pretty Unique To Me
  • 14. Entities
    Entities are the “things” within your Model
    An Entity is defined by being unique, and uniquely identifiable
    Entities have behaviour
  • 15. You Can’t Tell One From Another
  • 16. Value Objects
    Value Objects are the “things” within your model that have no uniqueness
    They are equal in all ways to another Value Object if all their properties match
    Value Objects are interchangeable
  • 17. How Can We Make Sense?
  • 18. Domain Model
    A Domain Model is a representation of the relationships between the Entities and Value Objects in your Domain
    It may look similar to UML or a class relationship diagram, but it is not one
    The Domain Model should be recognisable and understandable by the business
  • 19. That’s a Lot of Bits
  • 20. Aggregates
    “An aggregate is a collection of items that are gathered together to form a total quantity” - Wikipedia
    An Aggregate Root is the root item containing a number of parts that form a whole
    An AR is more likely to match a Use Case than any model structure
  • 21. Everyone Loves an Event!
  • 22. Domain Events
    The “3rd Thing” in DDD
    Like all events, notification that “something happened”
    They are in the past tense, and should be named accordingly
    Closely aligned to your Domain Model
    Will probably be handled by your messaging layer
  • 23.
  • 24. Bounded Contexts
    When you have multiple models you should consider Bounded Contexts
    Each BC is a self contained “mini application” containing it’s own model, persistence and code base
    Within a BC, everything should be strictly consistent
    To map between BCs you use a Context Map
  • 25. Transformer Domain
    Vehicle Domain
  • 26. Context Maps
    A Context Map provides a clearly defined relationship between Bounded Contexts and the interactions between their Domain Models
    A Context Map may be represented in many forms, but it comprises the rules for how to turn A into B
  • 27.
  • 28. Persistence Ignorance
    Subtitled “There Is No Database” 
    DDD uses the Repository pattern to create Persistence Ignorance
    A Repository represents itself as an in-memory list of items
    Repositories are specific to Aggregate Roots, not to Entities
  • 29.
  • 30. Anti-Corruption Layers
    An Anti-Corruption Layer is a method to isolate two systems, allowing systems to be integrated without knowledge of each other
    An ACL presents a Facade to both systems, defined in terms of their specific models
    ACLs maintain the integrity of a Domain
  • 31.
  • 32. Factors For Success of DDD
    Your domain is not trivial
    You have access to Domain Experts
    You have an iterative process
    You have a skilled and motivated team
  • 33. Where Does DDD Work Best?
    Domain Driven Design is
    a way of dealing with complexity
    DDD is ideally suited to Behaviour Centric SystemsnotData Centric systems
  • 34. Messaging Architectures
    DDD is ideally suited to Message Based Architectures
    DDD is ideally suited to Commands and Events
    DDD without Commands and Events is going to be a lot of hard work
    DDD is ideally suited to providing multiple autonomous systems that are loosely coupled
  • 35. CAP Theorem
    Consistency: The client perceives that a set of operations has occurred all at once.
    Availability: Every operation must terminate in an intended response.
    Partition tolerance: Operations will complete, even if individual components are unavailable.
    You cannot have all three
  • 36. ACID
    Atomicity, Consistent, Isolation, Durability
    Gives you Consistency and Availability
    Sacrifices Partition Tolerance
    Meaning: ACID systems are hard and expensive to scale
  • 37. BASE
    Basically Available, Soft state, Eventually consistent
    Gives you Availability and Partition Tolerance
    Sacrifices Consistency
    Meaning BASE systems can scale easily and are very fault tolerant
  • 38. BASE at a Database Level
    Most RDBMS databases are ACID
    Most NoSQL databases are BASE
    The largest expense in database systems is in fault tolerance and scaling
    BASE databases scale massively and cheaply
    BASE databases are highly fault tolerant
  • 39. BASE at an Architectural Level
    Latency is the biggest constraint on architecture
    Unless you have pessimistic locking, all data is stale
    Most mistakes in developer code are around consistency vs. latency
    The main cause of rigidity and fragility in systems is due to trying to maintain consistency
    Command Query Responsibility Segregation gives us BASE at an architectural level
  • 40. Command Query Responsibility Segregation (CQRS)
    Bertrand Meyer principle of CQS:every method should either be a command that performs an action, or a query that returns data to the caller
    At an architectural level this means:either issue commands, or issue queries, but never both
    And, query from a separate source from your domain commands
  • 41. CQRS in a Picture
    Client
    Command
    Domain
    Event Handlers
    Queries
    (synchronous no bus)
    Event Handlers
    Publish
    Persist
    Update
    Domain Persistence
    Read Model
  • 42. CQRS in a Simpler Picture
    Domain
    Read Model
    Events
    Commands
    DTOs
    Client
  • 43. CQRS Useful Only for Scaling?
    CQRS gives us hugely simplified Domain persistence and leaves the Domain free of orthogonal concerns
    CQRS lets us focus on real Domain logic
    CQRS gives us optimised reporting and querying capability
    CQRS removes a large amount of the effort involved in dealing with inconsistent systems pretending to be consistent
    CQRS has real business benefits beyond scaling
  • 44. Questions?
    Jak Charlton
    jak@thinkddd.com
    www.thinkddd.com
    Readify
    www.readify.net

×