Domain Driven Design
Download as PPTX, PDF46 likes9,987 views
The document discusses Domain Driven Design (DDD), a software development approach that focuses on building an object-oriented model of the domain that software needs to represent. It emphasizes modeling the domain closely after the structure and language of the problem domain. Key aspects of DDD discussed include ubiquitous language, bounded contexts, entities, value objects, aggregate roots, repositories, specifications, domain services, modules, domain events, and command query separation. DDD is best suited for projects with a significant domain complexity where closely modeling the problem domain can help manage that complexity.
Domain Driven Design
- 1. Domain Driven DesignRyan RileyCatapult Systems, Inc.
- 2. Domain Driven DesignWhen you remember that DDD is really just “OO software done right”, it becomes more obviousthat strong OO experience will also stand you in good stead when approaching DDD.- Jak Charlton, Domain Driven Design Step-by-Step
- 4. Entities
- 8. Repository
- 10. Domain Services
- 11. Modules
- 12. Domain Events
- 13. State Machines
- 14. Conceptual
- 16. Bounded Contexts
- 18. Refactoring
- 20. When to use DDDDomain Driven DesignConceptual Elements(or what it means)
- 21. Domain Driven DesignDomain Driven DesignDomain First
- 22. Focus on the Object Model
- 23. Focus on Object-Oriented Design
- 24. Works well with other *DD methods to:
- 26. Increase MaintainabilityDomain Driven DesignUbiquitous LanguageModel the language used by your domain experts
- 27. Nouns == Classes
- 28. Verbs == methods, services, etc.
- 29. Example: A Hiring Specialist may post Jobs to the Job Board.
- 30. Classes = Job, JobBoard
- 31. Actions = JobBoard.PostJob(Job)Domain Driven DesignBounded ContextsOne of many integration patterns
- 33. Shared Kernel
- 35. Conformist
- 37. Separate Ways
- 38. More than One Ubiquitous Language
- 41. Department terminologyDomain Driven DesignPersistence IgnoranceWhy is this important?
- 43. Focus on the domain, not the data structure
- 44. Quickly swap out repositories for testing, POC, etc.
- 45. How?
- 46. Plain Old CLR Objects (POCO)
- 47. Repository pattern (abstract the data access)
- 48. Aggregate Roots
- 49. More on this in a minuteDomain Driven DesignPersistence IgnoranceUIApplication /ServiceDomainData AccessInfrastructure
- 50. Domain Driven DesignRefactoring“Refactor to deeper insights”
- 51. Include your domain experts in your refactoring
- 52. Refactor your ubiquitous language 1st, your code 2nd
- 53. This doesn’t mean refactor for greater reusability
- 55. Initially used Retro disbursements for final partial-month payments
- 56. Realized that these required different actions
- 57. Symptom: confusion around the name Retro when talking about Final Partial PaymentsDomain Driven DesignCommand Query SeparationUser InterfaceCommandsQuery / ReportingServiceCommandsDomainEventsEventsInfrastructureEvent Store
- 58. Domain Driven DesignCommand Query SeparationOrigins – Eiffel language
- 59. Use for Distributed architectures
- 60. Move from class method level to the architectural level
- 61. Separate Bounded Contexts for reading and writing
- 62. Write == Commands == Change state and return nothing
- 63. Read == Queries == Pure functions that do not change state
- 64. Optimize each side differently
- 65. Focus on:
- 66. Event-Driven Architecture with Domain Events
- 67. State Machines
- 68. Allows easy transitions to:
- 71. Massive scalabilityDomain Driven DesignWhen to use DDDNow! (Not really)
- 72. Fits approximately 5% of development project needsDDD is a software methodology suited to a particular kind of application – one where there issignificant complexity, and there is a significant focus on a well defined business model.- Jak Charlton, Domain Driven Design Step-by-Step
- 73. Domain Driven DesignPatterns(or how it works)
- 74. Domain Driven DesignEntitiesA 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.Dr. David West, Object ThinkingWhen 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.- Rocky Lhotka, http://www.theserverside.net/tt/articles/showarticle.tss?id=BusinessObjects
- 75. Domain Driven DesignEntities, cont.The Domain Model pattern:
- 76. Structure
- 77. Behavior
- 78. No persistence behavior (i.e. Active Record)
- 79. Uniquely identified and tracked
- 80. Associated with other objects
- 81. Simplify
- 82. Remove unnecessary associationsDomain Driven DesignValue ObjectsNothing special (no identity)
- 83. Don’t confuse with value type
- 84. Immutable
- 85. One instance can be used for in multiple entities
- 86. Examples:
- 87. Money
- 89. CodesDomain Driven DesignAggregate RootsA complete and meaningful representation
- 90. Based on a single root (Entity)
- 91. Some entities or value objects don’t mean much alone
- 92. Maintains state for a collection of objects
- 93. Serves as a boundary between the objects inside and those outside
- 94. Simplifies access to the associated objects
- 95. The root has global identity and maintains invariants
- 96. Aggregates may be nested
- 97. Don’t go too deep!
- 98. Examples:
- 99. Job Board (Job)
- 101. Applicant (Applicant Skill)Domain Driven DesignObject Creation PatternsAid in object creation
- 102. Entities and Value Objects should ALWAYS be valid!
- 103. Constructors
- 104. Factory
- 105. Simple Factory (Factory Method moved up to its own class)
- 106. Factory Method (static method)
- 107. Abstract Factory (composes from parts via inheritance)
- 108. Builder
- 109. Fluent Interfaces
- 111. Other Gang of Four patternsDomain Driven DesignRepositoryAbstraction over data access
- 112. Acts as a collection of Aggregate Roots
- 113. Various approaches:
- 114. Repository per Aggregate (very explicit)
- 115. Generic Repository
- 116. Repository per aggregate built upon Generic Repository Strategy
- 117. Generic Repository with Specifications
- 118. Used for querying and adding/removing
- 119. Some implementations also add an Update
- 120. Generally used along with a Unit of Work (e.g. DataContext)Domain Driven DesignRepository per AggregateExplicit query methods:
- 121. GetById(int id)
- 123. GetByCityAndState(City city, State state)
- 125. Pros:
- 126. Very explicit and intentional interface so it reads better
- 127. Restrict data access to what you want to allow developers
- 128. Can more easily optimize each query
- 129. Cons:
- 130. Very manual process to create
- 131. Cannot reuse methods for other purposes
- 132. Extension requires editing the classDomain Driven DesignGeneric RepositoryGeneric, open query methods:
- 133. GetByKey(TKey key)
- 135. Insert(T entity)
- 136. Delete(T entity)
- 137. Update(T entity) ?
- 138. Pros:
- 139. Very re-usable; write once, use everywhere
- 140. Easy to code-gen for extension using partial classes
- 141. More directly mimics database operations against a table
- 142. Cons:
- 144. Little control over what happens on insert, delete, etc.
- 145. Exposes methods you may not want exposedDomain Driven DesignRepository per Aggregate w/ Generic StrategyMix the best of both worlds:
- 146. GetById(int id) : Query(p => p.Id == id)
- 147. GetByName(string name) : Query(p => p.Name == name)
- 148. Add(Person person) : Insert(person)
- 149. Pros:
- 150. Very explicit and intentional interface so it reads better
- 151. Restrict data access to what you want to allow developers
- 152. Can more easily optimize each query
- 153. Standardize data access mechanics
- 154. Simplify query construction in the repository
- 155. Easier to swap out persistence technology (database / in-memory)
- 157. Cons:
- 158. More code than Generic Repository
- 159. More moving piecesDomain Driven DesignGeneric Repository with SpecificationsGeneric functionality with explicit query functionality:
- 161. Add(T entity)
- 162. Pros:
- 164. Same reusability as Generic Repository
- 165. Extend by creating new specifications
- 166. Specifications can be used for more than querying (e.g. rules, etc.)
- 167. Cons:
- 168. Add, Remove, etc. may still be limited(but you probably shouldn’t do much else there anyway)
- 169. May be difficult to tie into your ORM(ExpressionVisitorreq’d for L2S or EF)
- 170. What is a Specification?!Domain Driven DesignSpecificationSimple interface for defining criteria:
- 172. Similar to the Query Object pattern
- 174. Very easy to test
- 175. Easy to chain together for more complex queries:
- 176. CompoiteSpecification: And, Or, Not
- 177. LINQPad uses PredicateBuilder for a similar effect
- 178. http://www.lostechies.com/blogs/chrismissal/archive/2009/09/10/using-the-specification-pattern-for-querying.aspxDomain Driven DesignDomain ServicesDo not confuse with Application Services
- 180. Actions that do not fit within an entity or aggregate
- 181. Stateless
- 182. Examples:
- 183. Transfers
- 184. CalculatorsDomain Driven DesignModulesBreak up your domain to reduce complexity
- 185. Becomes part of the ubiquitous language
- 187. Aids in extensibilityDomain Driven DesignDomain Events (CQS)These are not delegate events
- 188. POCO messages
- 189. IPublish and IHandle
- 190. Domain Models (Aggregates) publish events instead of saving to the database
- 191. Eventual consistency (just like every other model)Domain Driven DesignState Machines (CQS)In CQS, you don’t change state, you publish changes
- 192. State Machines: transition from one state to another
- 193. Domain Model (Aggregate) defines transitions
- 194. Examples:
- 195. HTTP
- 196. StatelessDomain Driven DesignSummaryUseful for very difficult and complex domains
- 197. Can help identify requirements
- 198. Focus on the language
- 199. Feel free to use patterns in other styles
- 200. Add Command Query Separation for distributed systemsDomain Driven DesignQuestions?
- 202. Domain Driven Design: Tackling Complexity in the Heart of Software
- 203. Applying Domain Driven Design and Patterns
- 204. Domain Driven Design Quickly (abbr. version of above)
- 205. Domain Driven Design Step-by-Step
- 206. ASP.NET MVC in Action
- 207. Blogs
- 208. Eric Evans
- 209. Jimmy Nilsson
- 210. Casey Charlton
- 211. Greg Young (Distributed DDD/CQS)