Downloaded 809 times
Uploaded byRyan Riley
Domain Driven Design
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.
More Related Content
Similar to Domain Driven Design
![UiPath Automation Suite Installation (Hands-On) [2/3]](https://cdn.slidesharecdn.com/ss_thumbnails/automationsuitecommunitysession2-251015095633-a6d862f1-thumbnail.jpg?width=600ounds&width=560&fit=bounds)
Domain Driven Design
- 1. Domain Driven DesignRyanRileyCatapult Systems, Inc.
- 2. Domain Driven DesignWhenyou 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
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20. When to useDDDDomain Driven DesignConceptual Elements(or what it means)
- 21. Domain Driven DesignDomainDriven DesignDomain First
- 22. Focus on theObject Model
- 23. Focus on Object-OrientedDesign
- 24. Works well withother *DD methods to:
- 25.
- 26. Increase MaintainabilityDomain DrivenDesignUbiquitous LanguageModel the language used by your domain experts
- 27.
- 28. Verbs == methods,services, etc.
- 29. Example: A HiringSpecialist may post Jobs to the Job Board.
- 30. Classes = Job,JobBoard
- 31. Actions = JobBoard.PostJob(Job)DomainDriven DesignBounded ContextsOne of many integration patterns
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38. More than OneUbiquitous Language
- 39.
- 40.
- 41. Department terminologyDomain DrivenDesignPersistence IgnoranceWhy is this important?
- 42.
- 43. Focus on thedomain, not the data structure
- 44. Quickly swap outrepositories for testing, POC, etc.
- 45.
- 46. Plain Old CLRObjects (POCO)
- 47. Repository pattern (abstractthe data access)
- 48.
- 49. More on thisin a minuteDomain Driven DesignPersistence IgnoranceUIApplication /ServiceDomainData AccessInfrastructure
- 50. Domain Driven DesignRefactoring“Refactorto deeper insights”
- 51. Include your domainexperts in your refactoring
- 52. Refactor your ubiquitouslanguage 1st, your code 2nd
- 53. This doesn’t meanrefactor for greater reusability
- 54.
- 55. Initially used Retrodisbursements for final partial-month payments
- 56. Realized that theserequired different actions
- 57. Symptom: confusion aroundthe name Retro when talking about Final Partial PaymentsDomain Driven DesignCommand Query SeparationUser InterfaceCommandsQuery / ReportingServiceCommandsDomainEventsEventsInfrastructureEvent Store
- 58. Domain Driven DesignCommandQuery SeparationOrigins – Eiffel language
- 59. Use for Distributedarchitectures
- 60. Move from classmethod level to the architectural level
- 61. Separate Bounded Contextsfor reading and writing
- 62. Write == Commands== Change state and return nothing
- 63. Read == Queries== Pure functions that do not change state
- 64. Optimize each sidedifferently
- 65.
- 66. Event-Driven Architecture withDomain Events
- 67.
- 68.
- 69.
- 70.
- 71. Massive scalabilityDomain DrivenDesignWhen 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(orhow it works)
- 74. Domain Driven DesignEntitiesAbehavioral 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.
- 77.
- 78. No persistence behavior(i.e. Active Record)
- 79. Uniquely identified andtracked
- 80. Associated with otherobjects
- 81.
- 82. Remove unnecessary associationsDomainDriven DesignValue ObjectsNothing special (no identity)
- 83. Don’t confuse withvalue type
- 84.
- 85. One instance canbe used for in multiple entities
- 86.
- 87.
- 88.
- 89. CodesDomain Driven DesignAggregateRootsA complete and meaningful representation
- 90. Based on asingle root (Entity)
- 91. Some entities orvalue objects don’t mean much alone
- 92. Maintains state fora collection of objects
- 93. Serves as aboundary between the objects inside and those outside
- 94. Simplifies access tothe associated objects
- 95. The root hasglobal identity and maintains invariants
- 96. Aggregates may benested
- 97. Don’t go toodeep!
- 98.
- 99.
- 100.
- 101. Applicant (Applicant Skill)DomainDriven DesignObject Creation PatternsAid in object creation
- 102. Entities and ValueObjects should ALWAYS be valid!
- 103.
- 104.
- 105. Simple Factory (FactoryMethod moved up to its own class)
- 106. Factory Method (staticmethod)
- 107. Abstract Factory (composesfrom parts via inheritance)
- 108.
- 109.
- 110.
- 111. Other Gang ofFour patternsDomain Driven DesignRepositoryAbstraction over data access
- 112. Acts as acollection of Aggregate Roots
- 113.
- 114. Repository per Aggregate(very explicit)
- 115.
- 116. Repository per aggregatebuilt upon Generic Repository Strategy
- 117. Generic Repository withSpecifications
- 118. Used for queryingand adding/removing
- 119. Some implementations alsoadd an Update
- 120. Generally used alongwith a Unit of Work (e.g. DataContext)Domain Driven DesignRepository per AggregateExplicit query methods:
- 121.
- 122.
- 123.
- 124.
- 125.
- 126. Very explicit andintentional interface so it reads better
- 127. Restrict data accessto what you want to allow developers
- 128. Can more easilyoptimize each query
- 129.
- 130. Very manual processto create
- 131. Cannot reuse methodsfor other purposes
- 132. Extension requires editingthe classDomain Driven DesignGeneric RepositoryGeneric, open query methods:
- 133.
- 134.
- 135.
- 136.
- 137.
- 138.
- 139. Very re-usable; writeonce, use everywhere
- 140. Easy to code-genfor extension using partial classes
- 141. More directly mimicsdatabase operations against a table
- 142.
- 143.
- 144. Little control overwhat happens on insert, delete, etc.
- 145. Exposes methods youmay 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.
- 150. Very explicit andintentional interface so it reads better
- 151. Restrict data accessto what you want to allow developers
- 152. Can more easilyoptimize each query
- 153. Standardize data accessmechanics
- 154. Simplify query constructionin the repository
- 155. Easier to swapout persistence technology (database / in-memory)
- 156.
- 157.
- 158. More code thanGeneric Repository
- 159. More moving piecesDomainDriven DesignGeneric Repository with SpecificationsGeneric functionality with explicit query functionality:
- 160.
- 161.
- 162.
- 163.
- 164. Same reusability asGeneric Repository
- 165. Extend by creatingnew specifications
- 166. Specifications can beused for more than querying (e.g. rules, etc.)
- 167.
- 168. Add, Remove, etc.may still be limited(but you probably shouldn’t do much else there anyway)
- 169. May be difficultto tie into your ORM(ExpressionVisitorreq’d for L2S or EF)
- 170. What is aSpecification?!Domain Driven DesignSpecificationSimple interface for defining criteria:
- 171.
- 172. Similar to theQuery Object pattern
- 173.
- 174. Very easy totest
- 175. Easy to chaintogether for more complex queries:
- 176.
- 177. LINQPad uses PredicateBuilderfor a similar effect
- 178. http://www.lostechies.com/blogs/chrismissal/archive/2009/09/10/using-the-specification-pattern-for-querying.aspxDomain Driven DesignDomainServicesDo not confuse with Application Services
- 179.
- 180. Actions that donot fit within an entity or aggregate
- 181.
- 182.
- 183.
- 184. CalculatorsDomain Driven DesignModulesBreakup your domain to reduce complexity
- 185. Becomes part ofthe ubiquitous language
- 186.
- 187. Aids in extensibilityDomainDriven DesignDomain Events (CQS)These are not delegate events
- 188.
- 189.
- 190. Domain Models (Aggregates)publish events instead of saving to the database
- 191. Eventual consistency (justlike every other model)Domain Driven DesignState Machines (CQS)In CQS, you don’t change state, you publish changes
- 192. State Machines: transitionfrom one state to another
- 193. Domain Model (Aggregate)defines transitions
- 194.
- 195.
- 196. StatelessDomain Driven DesignSummaryUsefulfor very difficult and complex domains
- 197. Can help identifyrequirements
- 198. Focus on thelanguage
- 199. Feel free touse patterns in other styles
- 200. Add Command QuerySeparation for distributed systemsDomain Driven DesignQuestions?
- 201.
- 202. Domain Driven Design:Tackling Complexity in the Heart of Software
- 203. Applying Domain DrivenDesign and Patterns
- 204. Domain Driven DesignQuickly (abbr. version of above)
- 205. Domain Driven DesignStep-by-Step
- 206. ASP.NET MVC inAction
- 207.
- 208.
- 209.
- 210.
- 211. Greg Young (DistributedDDD/CQS)