Your SlideShare is downloading. ×
Domain Driven Design
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

Domain Driven Design

1,250
views

Published on

Short Domain Driven Design and UML Refresher

Short Domain Driven Design and UML Refresher

Published in: Technology, Business

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,250
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
46
Comments
0
Likes
2
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. Thursday, March 1, 2012
  • 2. Domain Driven Design short Refresher FLOW3 Usergroup @AOE by Daniel PötzingerThursday, March 1, 2012
  • 3. Thursday, March 1, 2012
  • 4. The problem that we want to solveThursday, March 1, 2012
  • 5. The problemThursday, March 1, 2012
  • 6. The problem ‣ We need to write an application that solves buissiness problemsThursday, March 1, 2012
  • 7. The problem ‣ We need to write an application that solves buissiness problems ‣ We want to use OOPThursday, March 1, 2012
  • 8. The problem ‣ We need to write an application that solves buissiness problems ‣ We want to use OOP ‣ We need to find a good design:Thursday, March 1, 2012
  • 9. The problem ‣ We need to write an application that solves buissiness problems ‣ We want to use OOP ‣ We need to find a good design: ‣ understanding the problem and the buissinessThursday, March 1, 2012
  • 10. The problem ‣ We need to write an application that solves buissiness problems ‣ We want to use OOP ‣ We need to find a good design: ‣ understanding the problem and the buissiness ‣ find understandable class-structureThursday, March 1, 2012
  • 11. The problem ‣ We need to write an application that solves buissiness problems ‣ We want to use OOP ‣ We need to find a good design: ‣ understanding the problem and the buissiness ‣ find understandable class-structure ‣ build maintainable software, that can be adjusted easy when the buissiness changesThursday, March 1, 2012
  • 12. Thursday, March 1, 2012
  • 13. Domain Model ?Thursday, March 1, 2012
  • 14. Domain Model ?Thursday, March 1, 2012
  • 15. Domain Model ‣ The domain model offers a simplified, abstract view of the problem Domain ModelThursday, March 1, 2012
  • 16. Domain Model ‣ The domain model offers a simplified, abstract view of the problem Domain Experts Domain ModelThursday, March 1, 2012
  • 17. Domain Model ‣ The domain model offers a simplified, abstract view of the problem Domain Experts Domain Model ImplementatorsThursday, March 1, 2012
  • 18. Domain Model ‣ The domain model offers a simplified, abstract view of the problem Domain Experts Domain Model ImplementatorsThursday, March 1, 2012
  • 19. Domain Model ‣ The domain model offers a simplified, abstract view of the problem Domain Experts Knowledge Crunching Domain Model & Analysis ImplementatorsThursday, March 1, 2012
  • 20. Domain Model ‣ The domain model offers a simplified, abstract view of the problem Domain Experts Knowledge Crunching Domain Model & Analysis ImplementatorsThursday, March 1, 2012
  • 21. Domain Model ‣ a common language should be used to describe the problem Ubiquitous Domain Language Uses terms Domain Experts Both understand Domain Model ImplementatorsThursday, March 1, 2012
  • 22. Domain Model ‣ a common language should be used to describe the problem Ubiquitous Domain Language Uses terms Domain Experts Both understand Domain Model ImplementatorsThursday, March 1, 2012
  • 23. Domain Model ‣ The Domain Model can be represented as Text, Speech or Code... Domain ModelThursday, March 1, 2012
  • 24. Domain Model ‣ The Domain Model can be represented as Text, Speech or Code... A customer can have multiple contracts. The customer gets monthly bills to his Text billing address. Domain ModelThursday, March 1, 2012
  • 25. Domain Model ‣ The Domain Model can be represented as Text, Speech or Code... A customer can have multiple contracts. The customer gets monthly bills to his Text billing address. Domain Model UMLThursday, March 1, 2012
  • 26. Domain Model ‣ The Domain Model can be represented as Text, Speech or Code... A customer can have multiple contracts. The customer gets monthly bills to his Text billing address. Domain Model UML CodeThursday, March 1, 2012
  • 27. Thursday, March 1, 2012
  • 28. UMLThursday, March 1, 2012
  • 29. UML •UML is perfect to describe, scetch or discuss a domain model. UML Structural Diagrams Behavioral Diagrams Class Diagrams Object Diagrams ... Sequence Diagrams Use Case Diagram ...Thursday, March 1, 2012
  • 30. UML - Class DiagramThursday, March 1, 2012
  • 31. UML - Class Diagram ‣ class diagram describes the attributes and operations of a class and also the constraints imposed on the system.Thursday, March 1, 2012
  • 32. UML - Class Diagram ‣ class diagram describes the attributes and operations of a class and also the constraints imposed on the system. ‣ Can be directly mapped to code (OOP)Thursday, March 1, 2012
  • 33. UML - Class Diagram ‣ class diagram describes the attributes and operations of a class and also the constraints imposed on the system. ‣ Can be directly mapped to code (OOP) ‣ Popular use-case is to explain conceptual important parts => keep it simple („draw it on a paper“)Thursday, March 1, 2012
  • 34. UML - Class Diagram - Examples ‣ classes with: ‣ attributes (<name>:<type> ) ‣ methods ‣ annotations and properties ‣ Associations ‣ Multiplicity, roles ‣ Traversal ‣ Aggregation, Composition ‣ Inheritance, Dependency ‣ Qualifier ‣ Association ClassThursday, March 1, 2012
  • 35. UML - Object Diagram ‣ Depend on class diagrams ‣ „Snapshot“ of instances and theire relations ‣ Perfect to understand object behaviour and their relationship from practical perspectiveThursday, March 1, 2012
  • 36. UML - Sequence Diagram ‣ Depend on class diagrams ‣ Perfect to explain how objects work together to „fulfill“ a use-case. ‣ useful to detect weakness and improvements in your designThursday, March 1, 2012
  • 37. Thursday, March 1, 2012
  • 38. Domain Driven Design BasicsThursday, March 1, 2012
  • 39. Domain Driven Design - Basics 1. Layered Architecture 2. Common Building Blocks and Rules 3. Find a „supple design“ 4. See the big pictureThursday, March 1, 2012
  • 40. DDD - Layered ArchitectureThursday, March 1, 2012
  • 41. DDD - Layered Architecture Logging Persitence Infrastructure / System Speaking to Webservices File FormatsThursday, March 1, 2012
  • 42. DDD - Layered Architecture Domain Model Core Business Logic Logging Persitence Infrastructure / System Speaking to Webservices File FormatsThursday, March 1, 2012
  • 43. DDD - Layered Architecture Application Layer (thin) Controller / (Export/Import) Domain Model Core Business Logic Logging Persitence Infrastructure / System Speaking to Webservices File FormatsThursday, March 1, 2012
  • 44. DDD - Layered Architecture User / Application Layer (thin) Controller / (Export/Import) Other Apps Domain Model Core Business Logic Logging Persitence Infrastructure / System Speaking to Webservices File FormatsThursday, March 1, 2012
  • 45. DDD - Layered Architecture Templates / Presentation Objects View User / Application Layer (thin) Controller / (Export/Import) Other Apps Domain Model Core Business Logic Logging Persitence Infrastructure / System Speaking to Webservices File FormatsThursday, March 1, 2012
  • 46. Thursday, March 1, 2012
  • 47. Building BlocksThursday, March 1, 2012
  • 48. Building BlocksThursday, March 1, 2012
  • 49. DDD - Building BlocksThursday, March 1, 2012
  • 50. DDD - Building Blocks EntitiesThursday, March 1, 2012
  • 51. DDD - Building Blocks Entities ValuesThursday, March 1, 2012
  • 52. DDD - Building Blocks Entities Values ServicesThursday, March 1, 2012
  • 53. DDD - Building Blocks Entities Repository Values ServicesThursday, March 1, 2012
  • 54. DDD - Building Blocks Entities Repository Values Factory ServicesThursday, March 1, 2012
  • 55. DDD - Building BlocksThursday, March 1, 2012
  • 56. DDD - Building Blocks EntitiesThursday, March 1, 2012
  • 57. DDD - Building Blocks Entities Object which is primary defined by its identity (not by attributes). For example "Person", "Car", "Costumer" or "BankTransaction".Thursday, March 1, 2012
  • 58. DDD - Building Blocks Entities Object which is primary defined by its identity (not by attributes). For example "Person", "Car", "Costumer" or "BankTransaction". • often has some ID valueThursday, March 1, 2012
  • 59. DDD - Building Blocks Entities Object which is primary defined by its identity (not by attributes). For example "Person", "Car", "Costumer" or "BankTransaction". • often has some ID value • continuity through livecycleThursday, March 1, 2012
  • 60. DDD - Building Blocks Entities Object which is primary defined by its identity (not by attributes). For example "Person", "Car", "Costumer" or "BankTransaction". • often has some ID value • continuity through livecycle • keep class definition simple / focus on live cycleThursday, March 1, 2012
  • 61. DDD - Building BlocksThursday, March 1, 2012
  • 62. DDD - Building Blocks ValueThursday, March 1, 2012
  • 63. DDD - Building Blocks Value describe the characteristic of a thing and identity is not required. (We care what they are - not who) Example: address, color ...Thursday, March 1, 2012
  • 64. DDD - Building Blocks Value describe the characteristic of a thing and identity is not required. (We care what they are - not who) Example: address, color ... • should represent a whole value (conceptual thing )Thursday, March 1, 2012
  • 65. DDD - Building Blocks Value describe the characteristic of a thing and identity is not required. (We care what they are - not who) Example: address, color ... • should represent a whole value (conceptual thing ) • Often passed as argumentsThursday, March 1, 2012
  • 66. DDD - Building Blocks Value describe the characteristic of a thing and identity is not required. (We care what they are - not who) Example: address, color ... • should represent a whole value (conceptual thing ) • Often passed as arguments • No Identity gives freedomThursday, March 1, 2012
  • 67. DDD - Building Blocks Value describe the characteristic of a thing and identity is not required. (We care what they are - not who) Example: address, color ... • should represent a whole value (conceptual thing ) • Often passed as arguments • No Identity gives freedom • should be Immutable!Thursday, March 1, 2012
  • 68. DDD - Building BlocksThursday, March 1, 2012
  • 69. DDD - Building Blocks ServiceThursday, March 1, 2012
  • 70. DDD - Building Blocks Service “...if a single process or transformation in domain is not a natural responsibility of an entity or value => make it a standalone service with a nice interface."Thursday, March 1, 2012
  • 71. DDD - Building Blocks Service “...if a single process or transformation in domain is not a natural responsibility of an entity or value => make it a standalone service with a nice interface." • statelessThursday, March 1, 2012
  • 72. DDD - Building Blocks Service “...if a single process or transformation in domain is not a natural responsibility of an entity or value => make it a standalone service with a nice interface." • stateless • offer a useful service or action and deals with other domain objectsThursday, March 1, 2012
  • 73. DDD - Building Blocks Service “...if a single process or transformation in domain is not a natural responsibility of an entity or value => make it a standalone service with a nice interface." • stateless • offer a useful service or action and deals with other domain objects • defined in common domain languageThursday, March 1, 2012
  • 74. DDD - Building Blocks Service “...if a single process or transformation in domain is not a natural responsibility of an entity or value => make it a standalone service with a nice interface." • stateless • offer a useful service or action and deals with other domain objects • defined in common domain language • do not mix with other layersThursday, March 1, 2012
  • 75. DDD - Building Blocks Service “...if a single process or transformation in domain is not a natural responsibility of an entity or value => make it a standalone service with a nice interface." • stateless • offer a useful service or action and deals with other domain objects • defined in common domain language • do not mix with other layers Examples: FundTransferService / PackageRoutingService / SimCardActivationServiceThursday, March 1, 2012
  • 76. DDD - Building BlocksThursday, March 1, 2012
  • 77. DDD - Building Blocks RepositoryThursday, March 1, 2012
  • 78. DDD - Building Blocks Repository For each object where you need global access create a repository object that can provide the illusion of an in memory collection of all objects of that type. Setup access through a well knows global interface.Thursday, March 1, 2012
  • 79. DDD - Building Blocks Repository For each object where you need global access create a repository object that can provide the illusion of an in memory collection of all objects of that type. Setup access through a well knows global interface. • typicaly methods for add() remove() and find*()Thursday, March 1, 2012
  • 80. DDD - Building Blocks Repository For each object where you need global access create a repository object that can provide the illusion of an in memory collection of all objects of that type. Setup access through a well knows global interface. • typicaly methods for add() remove() and find*() •find* methods communicate design decisions about how to access the dataThursday, March 1, 2012
  • 81. DDD - Building Blocks Repository For each object where you need global access create a repository object that can provide the illusion of an in memory collection of all objects of that type. Setup access through a well knows global interface. • typicaly methods for add() remove() and find*() •find* methods communicate design decisions about how to access the data • ..reconstitution?Thursday, March 1, 2012
  • 82. DDD - Building BlocksThursday, March 1, 2012
  • 83. DDD - Building Blocks FactoryThursday, March 1, 2012
  • 84. DDD - Building Blocks Factory A factory hides logic for building objects - this is especially relevant for aggregates!Thursday, March 1, 2012
  • 85. DDD - Building Blocks Factory A factory hides logic for building objects - this is especially relevant for aggregates! • atomic (need to pass all essential parameters)Thursday, March 1, 2012
  • 86. DDD - Building Blocks Factory A factory hides logic for building objects - this is especially relevant for aggregates! • atomic (need to pass all essential parameters) • not allowed to give wrong results (exceptions)Thursday, March 1, 2012
  • 87. DDD - Building Blocks Factory A factory hides logic for building objects - this is especially relevant for aggregates! • atomic (need to pass all essential parameters) • not allowed to give wrong results (exceptions) • entity vs. value factoriesThursday, March 1, 2012
  • 88. DDD - Building Blocks Factory A factory hides logic for building objects - this is especially relevant for aggregates! • atomic (need to pass all essential parameters) • not allowed to give wrong results (exceptions) • entity vs. value factories • (can also be used for reconstitution )Thursday, March 1, 2012
  • 89. Thursday, March 1, 2012
  • 90. Find a Supple DesignThursday, March 1, 2012
  • 91. Find a Supple Design vs.Thursday, March 1, 2012
  • 92. Supple Design „Speak in Domain Language“Thursday, March 1, 2012
  • 93. Supple Design „Speak in Domain Language“ ‣ Try to explain scenarios loud with the use of the model and the ubiquitous languageThursday, March 1, 2012
  • 94. Supple Design „Speak in Domain Language“ ‣ Try to explain scenarios loud with the use of the model and the ubiquitous language ‣ Try to explain scenarios more simple/better (find easier ways to say what you need to say). => That helps refining the model.Thursday, March 1, 2012
  • 95. Supple Design „Reduce Associations“Thursday, March 1, 2012
  • 96. Supple Design „Reduce Associations“ ‣ Avoid many association and use only a minimum of relations because they decrease maintainability!Thursday, March 1, 2012
  • 97. Supple Design „Reduce Associations“ ‣ Avoid many association and use only a minimum of relations because they decrease maintainability! ‣ traversal instead of bidirectionalThursday, March 1, 2012
  • 98. Supple Design „Reduce Associations“ ‣ Avoid many association and use only a minimum of relations because they decrease maintainability! ‣ traversal instead of bidirectional ‣ adding qualifier to reduce multiplicity (class missing?)Thursday, March 1, 2012
  • 99. Supple Design „Reduce Associations“ ‣ Avoid many association and use only a minimum of relations because they decrease maintainability! ‣ traversal instead of bidirectional ‣ adding qualifier to reduce multiplicity (class missing?) ‣ eliminate non essential assoc.Thursday, March 1, 2012
  • 100. Supple Design „Reduce Associations“ ‣ Avoid many association and use only a minimum of relations because they decrease maintainability! ‣ traversal instead of bidirectional ‣ adding qualifier to reduce multiplicity (class missing?) ‣ eliminate non essential assoc. ‣ find and use aggregatesThursday, March 1, 2012
  • 101. Supple Design „Reduce Associations“ ‣ Avoid many association and use only a minimum of relations because they decrease maintainability! ‣ traversal instead of bidirectional ‣ adding qualifier to reduce multiplicity (class missing?) ‣ eliminate non essential assoc. ‣ find and use aggregates => Intuition and RefactoringThursday, March 1, 2012
  • 102. Supple Design „Reduce Associations“ ‣ Avoid many association and use only a minimum of relations because they decrease maintainability! ‣ traversal instead of bidirectional ‣ adding qualifier to reduce multiplicity (class missing?) ‣ eliminate non essential assoc. ‣ find and use aggregates => Intuition and Refactoring ... country / president example ...Thursday, March 1, 2012
  • 103. Supple Design - AggregatesThursday, March 1, 2012
  • 104. Supple Design - Aggregates ‣ An aggregate is a group of objects that belong together (a group of individual objects that represents a unit)Thursday, March 1, 2012
  • 105. Supple Design - Aggregates ‣ An aggregate is a group of objects that belong together (a group of individual objects that represents a unit) ‣ ...car example... (root, boundary, invariants )Thursday, March 1, 2012
  • 106. Supple Design - „Explicit constrains“Thursday, March 1, 2012
  • 107. Supple Design - „Explicit constrains“ ‣ name and make constrains explicit. That gives it a name you can talk about and the code is more understandableThursday, March 1, 2012
  • 108. Supple Design - „Explicit constrains“ ‣ name and make constrains explicit. That gives it a name you can talk about and the code is more understandable Bucket exampleThursday, March 1, 2012
  • 109. Supple Design - „Specifications“Thursday, March 1, 2012
  • 110. Supple Design - „Specifications“ ‣ you can use „Specifications“ to explicit express rulesThursday, March 1, 2012
  • 111. Supple Design - „Specifications“ ‣ you can use „Specifications“ to explicit express rules examples:Thursday, March 1, 2012
  • 112. Supple Design - „Specifications“ ‣ you can use „Specifications“ to explicit express rules examples: „InventoryDelinquentSpecification“->isSatisfied()Thursday, March 1, 2012
  • 113. Supple Design - „Specifications“ ‣ you can use „Specifications“ to explicit express rules examples: „InventoryDelinquentSpecification“->isSatisfied() „GoldenCustomerSpecification“->isSatisfied($customer)Thursday, March 1, 2012
  • 114. Supple Design - Modules If your model tells a story a module is a chapterThursday, March 1, 2012
  • 115. Supple Design - Modules Customer Order Customer Contract Basket Order OrderItems Product AbstractProduct PrepaidThursday, March 1, 2012
  • 116. Supple Design - Modules Customer Order Customer Contract Basket Order OrderItems Product AbstractProduct • group by meaning in the domain PrepaidThursday, March 1, 2012
  • 117. Supple Design - Modules Customer Order Customer Contract Basket Order OrderItems Product AbstractProduct • group by meaning in the domain • loose coupling between modules PrepaidThursday, March 1, 2012
  • 118. Supple Design - What elseThursday, March 1, 2012
  • 119. Supple Design - What else • Intention Revalving InterfacesThursday, March 1, 2012
  • 120. Supple Design - What else • Intention Revalving Interfaces • standalone classes where possibleThursday, March 1, 2012
  • 121. Supple Design - What else • Intention Revalving Interfaces • standalone classes where possible • closure of operationsThursday, March 1, 2012
  • 122. Supple Design - What else • Intention Revalving Interfaces • standalone classes where possible • closure of operations • side effect free functionsThursday, March 1, 2012
  • 123. Thank you for great year!Thursday, March 1, 2012
  • 124. Thank you for great year! ThanksThursday, March 1, 2012