Domain Driven Design

  • 1,171 views
Uploaded on

Short Domain Driven Design and UML Refresher

Short Domain Driven Design and UML Refresher

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,171
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
45
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