0
Domain Driven Design<br />Ryan Riley<br />Catapult Systems, Inc.<br />
Domain Driven Design<br />When you remember that DDD is really just “OO software done right”, it becomes more obvious<br /...
Domain Driven Design<br />Agenda<br /><ul><li>Patterns
Entities
Value Objects
Aggregate Roots
Object Creation Patterns
Repository
Specification
Domain Services
Modules
Domain Events
State Machines
Conceptual
Ubiquitous Language
Bounded Contexts
Persistence Ignorance
Refactoring
Command Query Separation
When to use DDD</li></li></ul><li>Domain Driven Design<br />Conceptual Elements<br />(or what it means)<br />
Domain Driven Design<br />Domain Driven Design<br /><ul><li>Domain First
Focus on the Object Model
Focus on Object-Oriented Design
Works well with other *DD methods to:
Reduce Complexity
Increase Maintainability</li></li></ul><li>Domain Driven Design<br />Ubiquitous Language<br /><ul><li>Model the language u...
Nouns == Classes
Verbs == methods, services, etc.
Example: A Hiring Specialist may post Jobs to the Job Board.
Classes = Job, JobBoard
Actions = JobBoard.PostJob(Job)</li></li></ul><li>Domain Driven Design<br />Bounded Contexts<br /><ul><li>One of many inte...
Continuous Integration
Upcoming SlideShare
Loading in...5
×

Domain Driven Design

8,978

Published on

I presented Domain Driven Design (and Command Query Separation) internally to my company.

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

No Downloads
Views
Total Views
8,978
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
447
Comments
0
Likes
26
Embeds 0
No embeds

No notes for slide

Transcript of "Domain Driven Design"

  1. 1. Domain Driven Design<br />Ryan Riley<br />Catapult Systems, Inc.<br />
  2. 2. Domain Driven Design<br />When you remember that DDD is really just “OO software done right”, it becomes more obvious<br />that strong OO experience will also stand you in good stead when approaching DDD.<br />- Jak Charlton, Domain Driven Design Step-by-Step<br />
  3. 3. Domain Driven Design<br />Agenda<br /><ul><li>Patterns
  4. 4. Entities
  5. 5. Value Objects
  6. 6. Aggregate Roots
  7. 7. Object Creation Patterns
  8. 8. Repository
  9. 9. Specification
  10. 10. Domain Services
  11. 11. Modules
  12. 12. Domain Events
  13. 13. State Machines
  14. 14. Conceptual
  15. 15. Ubiquitous Language
  16. 16. Bounded Contexts
  17. 17. Persistence Ignorance
  18. 18. Refactoring
  19. 19. Command Query Separation
  20. 20. When to use DDD</li></li></ul><li>Domain Driven Design<br />Conceptual Elements<br />(or what it means)<br />
  21. 21. Domain Driven Design<br />Domain Driven Design<br /><ul><li>Domain First
  22. 22. Focus on the Object Model
  23. 23. Focus on Object-Oriented Design
  24. 24. Works well with other *DD methods to:
  25. 25. Reduce Complexity
  26. 26. Increase Maintainability</li></li></ul><li>Domain Driven Design<br />Ubiquitous Language<br /><ul><li>Model the language used by your domain experts
  27. 27. Nouns == Classes
  28. 28. Verbs == methods, services, etc.
  29. 29. Example: A Hiring Specialist may post Jobs to the Job Board.
  30. 30. Classes = Job, JobBoard
  31. 31. Actions = JobBoard.PostJob(Job)</li></li></ul><li>Domain Driven Design<br />Bounded Contexts<br /><ul><li>One of many integration patterns
  32. 32. Continuous Integration
  33. 33. Shared Kernel
  34. 34. Customer / Supplier
  35. 35. Conformist
  36. 36. Anticorruption Layer
  37. 37. Separate Ways
  38. 38. More than One Ubiquitous Language
  39. 39. Applicant terminology
  40. 40. Hiring Specialist terminology
  41. 41. Department terminology</li></li></ul><li>Domain Driven Design<br />Persistence Ignorance<br /><ul><li>Why is this important?
  42. 42. Model-driven, not data-driven
  43. 43. Focus on the domain, not the data structure
  44. 44. Quickly swap out repositories for testing, POC, etc.
  45. 45. How?
  46. 46. Plain Old CLR Objects (POCO)
  47. 47. Repository pattern (abstract the data access)
  48. 48. Aggregate Roots
  49. 49. More on this in a minute</li></li></ul><li>Domain Driven Design<br />Persistence Ignorance<br />UI<br />Application /Service<br />Domain<br />Data Access<br />Infrastructure<br />
  50. 50. Domain Driven Design<br />Refactoring<br /><ul><li>“Refactor to deeper insights”
  51. 51. Include your domain experts in your refactoring
  52. 52. Refactor your ubiquitous language 1st, your code 2nd
  53. 53. This doesn’t mean refactor for greater reusability
  54. 54. Example: benefit disbursements
  55. 55. Initially used Retro disbursements for final partial-month payments
  56. 56. Realized that these required different actions
  57. 57. Symptom: confusion around the name Retro when talking about Final Partial Payments</li></li></ul><li>Domain Driven Design<br />Command Query Separation<br />User Interface<br />Commands<br />Query / Reporting<br />Service<br />Commands<br />Domain<br />Events<br />Events<br />Infrastructure<br />Event Store<br />
  58. 58. Domain Driven Design<br />Command Query Separation<br /><ul><li>Origins – Eiffel language
  59. 59. Use for Distributed architectures
  60. 60. Move from class method level to the architectural level
  61. 61. Separate Bounded Contexts for reading and writing
  62. 62. Write == Commands == Change state and return nothing
  63. 63. Read == Queries == Pure functions that do not change state
  64. 64. Optimize each side differently
  65. 65. Focus on:
  66. 66. Event-Driven Architecture with Domain Events
  67. 67. State Machines
  68. 68. Allows easy transitions to:
  69. 69. Messaging services
  70. 70. Asynchronous processing
  71. 71. Massive scalability</li></li></ul><li>Domain Driven Design<br />When to use DDD<br /><ul><li>Now! (Not really)
  72. 72. Fits approximately 5% of development project needs</li></ul>DDD is a software methodology suited to a particular kind of application – one where there is<br />significant complexity, and there is a significant focus on a well defined business model.<br />- Jak Charlton, Domain Driven Design Step-by-Step<br />
  73. 73. Domain Driven Design<br />Patterns<br />(or how it works)<br />
  74. 74. Domain Driven Design<br />Entities<br />A behavioral approach mandates the assignment of responsibilities first. Only when you are satisfied with the distribution of responsibilities among your objects are you ready to make a decision about what they need to know…. Behavior is the only criterion we use to differentiate among objects.<br /><ul><li>Dr. David West, Object Thinking</li></ul>When data is the center piece of your object, you assign data to objects before saying what they do. Descriptions of data don’t tell you squat about your objects.<br />- Rocky Lhotka, http://www.theserverside.net/tt/articles/showarticle.tss?id=BusinessObjects<br />
  75. 75. Domain Driven Design<br />Entities, cont.<br /><ul><li>The Domain Model pattern:
  76. 76. Structure
  77. 77. Behavior
  78. 78. No persistence behavior (i.e. Active Record)
  79. 79. Uniquely identified and tracked
  80. 80. Associated with other objects
  81. 81. Simplify
  82. 82. Remove unnecessary associations</li></li></ul><li>Domain Driven Design<br />Value Objects<br /><ul><li>Nothing special (no identity)
  83. 83. Don’t confuse with value type
  84. 84. Immutable
  85. 85. One instance can be used for in multiple entities
  86. 86. Examples:
  87. 87. Money
  88. 88. Address (usually)
  89. 89. Codes</li></li></ul><li>Domain Driven Design<br />Aggregate Roots<br /><ul><li>A complete and meaningful representation
  90. 90. Based on a single root (Entity)
  91. 91. Some entities or value objects don’t mean much alone
  92. 92. Maintains state for a collection of objects
  93. 93. Serves as a boundary between the objects inside and those outside
  94. 94. Simplifies access to the associated objects
  95. 95. The root has global identity and maintains invariants
  96. 96. Aggregates may be nested
  97. 97. Don’t go too deep!
  98. 98. Examples:
  99. 99. Job Board (Job)
  100. 100. Job (Skill, Applicant)
  101. 101. Applicant (Applicant Skill)</li></li></ul><li>Domain Driven Design<br />Object Creation Patterns<br /><ul><li>Aid in object creation
  102. 102. Entities and Value Objects should ALWAYS be valid!
  103. 103. Constructors
  104. 104. Factory
  105. 105. Simple Factory (Factory Method moved up to its own class)
  106. 106. Factory Method (static method)
  107. 107. Abstract Factory (composes from parts via inheritance)
  108. 108. Builder
  109. 109. Fluent Interfaces
  110. 110. Example: String Builder
  111. 111. Other Gang of Four patterns</li></li></ul><li>Domain Driven Design<br />Repository<br /><ul><li>Abstraction over data access
  112. 112. Acts as a collection of Aggregate Roots
  113. 113. Various approaches:
  114. 114. Repository per Aggregate (very explicit)
  115. 115. Generic Repository
  116. 116. Repository per aggregate built upon Generic Repository Strategy
  117. 117. Generic Repository with Specifications
  118. 118. Used for querying and adding/removing
  119. 119. Some implementations also add an Update
  120. 120. Generally used along with a Unit of Work (e.g. DataContext)</li></li></ul><li>Domain Driven Design<br />Repository per Aggregate<br /><ul><li>Explicit query methods:
  121. 121. GetById(int id)
  122. 122. GetByName(string name)
  123. 123. GetByCityAndState(City city, State state)
  124. 124. AddApplicant(Applicant person)
  125. 125. Pros:
  126. 126. Very explicit and intentional interface so it reads better
  127. 127. Restrict data access to what you want to allow developers
  128. 128. Can more easily optimize each query
  129. 129. Cons:
  130. 130. Very manual process to create
  131. 131. Cannot reuse methods for other purposes
  132. 132. Extension requires editing the class</li></li></ul><li>Domain Driven Design<br />Generic Repository<br /><ul><li>Generic, open query methods:
  133. 133. GetByKey<TKey>(TKey key)
  134. 134. Query<T>(Expression<Func<T>> query)
  135. 135. Insert<T>(T entity)
  136. 136. Delete<T>(T entity)
  137. 137. Update<T>(T entity) ?
  138. 138. Pros:
  139. 139. Very re-usable; write once, use everywhere
  140. 140. Easy to code-gen for extension using partial classes
  141. 141. More directly mimics database operations against a table
  142. 142. Cons:
  143. 143. Not intentional (Expressions?!)
  144. 144. Little control over what happens on insert, delete, etc.
  145. 145. Exposes methods you may not want exposed</li></li></ul><li>Domain Driven Design<br />Repository per Aggregate w/ Generic Strategy<br /><ul><li>Mix the best of both worlds:
  146. 146. GetById(int id) : Query<Person>(p => p.Id == id)
  147. 147. GetByName(string name) : Query<Person>(p => p.Name == name)
  148. 148. Add(Person person) : Insert<Person>(person)
  149. 149. Pros:
  150. 150. Very explicit and intentional interface so it reads better
  151. 151. Restrict data access to what you want to allow developers
  152. 152. Can more easily optimize each query
  153. 153. Standardize data access mechanics
  154. 154. Simplify query construction in the repository
  155. 155. Easier to swap out persistence technology (database / in-memory)
  156. 156. Composition over Inheritance
  157. 157. Cons:
  158. 158. More code than Generic Repository
  159. 159. More moving pieces</li></li></ul><li>Domain Driven Design<br />Generic Repository with Specifications<br /><ul><li>Generic functionality with explicit query functionality:
  160. 160. Query<T>(ISpecification<T> specification)
  161. 161. Add<T>(T entity)
  162. 162. Pros:
  163. 163. Extremely intention revealing
  164. 164. Same reusability as Generic Repository
  165. 165. Extend by creating new specifications
  166. 166. Specifications can be used for more than querying (e.g. rules, etc.)
  167. 167. Cons:
  168. 168. Add, Remove, etc. may still be limited(but you probably shouldn’t do much else there anyway)
  169. 169. May be difficult to tie into your ORM(ExpressionVisitorreq’d for L2S or EF)
  170. 170. What is a Specification?!</li></li></ul><li>Domain Driven Design<br />Specification<br /><ul><li>Simple interface for defining criteria:
  171. 171. IsSatisfiedBy(T entity)
  172. 172. Similar to the Query Object pattern
  173. 173. Very intention revealing
  174. 174. Very easy to test
  175. 175. Easy to chain together for more complex queries:
  176. 176. CompoiteSpecification: And, Or, Not
  177. 177. LINQPad uses PredicateBuilder for a similar effect
  178. 178. http://www.lostechies.com/blogs/chrismissal/archive/2009/09/10/using-the-specification-pattern-for-querying.aspx</li></li></ul><li>Domain Driven Design<br />Domain Services<br /><ul><li>Do not confuse with Application Services
  179. 179. Defining characteristics:
  180. 180. Actions that do not fit within an entity or aggregate
  181. 181. Stateless
  182. 182. Examples:
  183. 183. Transfers
  184. 184. Calculators</li></li></ul><li>Domain Driven Design<br />Modules<br /><ul><li>Break up your domain to reduce complexity
  185. 185. Becomes part of the ubiquitous language
  186. 186. Helps with decoupling
  187. 187. Aids in extensibility</li></li></ul><li>Domain Driven Design<br />Domain Events (CQS)<br /><ul><li>These are not delegate events
  188. 188. POCO messages
  189. 189. IPublish<TEvent> and IHandle<TEvent>
  190. 190. Domain Models (Aggregates) publish events instead of saving to the database
  191. 191. Eventual consistency (just like every other model)</li></li></ul><li>Domain Driven Design<br />State Machines (CQS)<br /><ul><li>In CQS, you don’t change state, you publish changes
  192. 192. State Machines: transition from one state to another
  193. 193. Domain Model (Aggregate) defines transitions
  194. 194. Examples:
  195. 195. HTTP
  196. 196. Stateless</li></li></ul><li>Domain Driven Design<br />Summary<br /><ul><li>Useful for very difficult and complex domains
  197. 197. Can help identify requirements
  198. 198. Focus on the language
  199. 199. Feel free to use patterns in other styles
  200. 200. Add Command Query Separation for distributed systems</li></li></ul><li>Domain Driven Design<br />Questions?<br />
  201. 201. Domain Driven Design<br />Resources<br /><ul><li>Books
  202. 202. Domain Driven Design: Tackling Complexity in the Heart of Software
  203. 203. Applying Domain Driven Design and Patterns
  204. 204. Domain Driven Design Quickly (abbr. version of above)
  205. 205. Domain Driven Design Step-by-Step
  206. 206. ASP.NET MVC in Action
  207. 207. Blogs
  208. 208. Eric Evans
  209. 209. Jimmy Nilsson
  210. 210. Casey Charlton
  211. 211. Greg Young (Distributed DDD/CQS)</li>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×