6. The problem
‣ We need to write an application that solves
buissiness problems
Thursday, March 1, 2012
7. The problem
‣ We need to write an application that solves
buissiness problems
‣ We want to use OOP
Thursday, 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 buissiness
Thursday, 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-structure
Thursday, 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 changes
Thursday, March 1, 2012
15. Domain Model
‣ The domain model offers a simplified, abstract view of
the problem
Domain Model
Thursday, March 1, 2012
16. Domain Model
‣ The domain model offers a simplified, abstract view of
the problem
Domain Experts
Domain Model
Thursday, March 1, 2012
17. Domain Model
‣ The domain model offers a simplified, abstract view of
the problem
Domain Experts
Domain Model
Implementators
Thursday, March 1, 2012
18. Domain Model
‣ The domain model offers a simplified, abstract view of
the problem
Domain Experts
Domain Model
Implementators
Thursday, March 1, 2012
19. Domain Model
‣ The domain model offers a simplified, abstract view of
the problem
Domain Experts
Knowledge Crunching Domain Model
& Analysis
Implementators
Thursday, March 1, 2012
20. Domain Model
‣ The domain model offers a simplified, abstract view of
the problem
Domain Experts
Knowledge Crunching Domain Model
& Analysis
Implementators
Thursday, 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
Implementators
Thursday, 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
Implementators
Thursday, March 1, 2012
23. Domain Model
‣ The Domain Model can be represented as Text, Speech
or Code...
Domain Model
Thursday, 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 Model
Thursday, 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
UML
Thursday, 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
Code
Thursday, 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
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 Class
Thursday, 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 perspective
Thursday, 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
design
Thursday, 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 picture
Thursday, March 1, 2012
41. DDD - Layered Architecture
Logging
Persitence
Infrastructure / System Speaking to Webservices
File Formats
Thursday, March 1, 2012
42. DDD - Layered Architecture
Domain Model Core Business Logic
Logging
Persitence
Infrastructure / System Speaking to Webservices
File Formats
Thursday, 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 Formats
Thursday, 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 Formats
Thursday, 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 Formats
Thursday, 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 value
Thursday, 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 livecycle
Thursday, 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 cycle
Thursday, 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 arguments
Thursday, 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 freedom
Thursday, 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
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."
• stateless
Thursday, 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
objects
Thursday, 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 language
Thursday, 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 layers
Thursday, 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 / SimCardActivationService
Thursday, March 1, 2012
77. DDD - Building Blocks
Repository
Thursday, 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 data
Thursday, 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
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 factories
Thursday, 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
93. Supple Design „Speak in Domain Language“
‣ Try to explain scenarios loud with the use of the model
and the ubiquitous language
Thursday, 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
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 bidirectional
Thursday, 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 aggregates
Thursday, 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 Refactoring
Thursday, 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
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
understandable
Thursday, 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 example
Thursday, March 1, 2012
110. Supple Design - „Specifications“
‣ you can use „Specifications“ to explicit express rules
Thursday, 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 chapter
Thursday, March 1, 2012
115. Supple Design - Modules
Customer Order
Customer Contract Basket Order
OrderItems
Product
AbstractProduct
Prepaid
Thursday, March 1, 2012
116. Supple Design - Modules
Customer Order
Customer Contract Basket Order
OrderItems
Product
AbstractProduct
• group by meaning in the domain
Prepaid
Thursday, 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
Prepaid
Thursday, March 1, 2012
119. Supple Design - What else
• Intention Revalving Interfaces
Thursday, March 1, 2012
120. Supple Design - What else
• Intention Revalving Interfaces
• standalone classes where possible
Thursday, March 1, 2012
121. Supple Design - What else
• Intention Revalving Interfaces
• standalone classes where possible
• closure of operations
Thursday, March 1, 2012
122. Supple Design - What else
• Intention Revalving Interfaces
• standalone classes where possible
• closure of operations
• side effect free functions
Thursday, March 1, 2012
