Practical Domain Driven Design, CQRS and Messaging Architectures


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 77 York St Sydney, NSW. 2000

Published in: Technology

Practical Domain Driven Design, CQRS and Messaging Architectures

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