domain driven design
Post on 09-May-2015
707 Views
Preview:
DESCRIPTION
TRANSCRIPT
Thursday, March 1, 2012
Domain Driven Designshort Refresher
FLOW3 Usergroup @AOEby Daniel Pötzinger
Thursday, March 1, 2012
Thursday, March 1, 2012
The problem that we want to solve
Thursday, March 1, 2012
The problem
Thursday, March 1, 2012
‣ We need to write an application that solves buissiness problems
The problem
Thursday, March 1, 2012
‣ We need to write an application that solves buissiness problems
‣ We want to use OOP
The problem
Thursday, March 1, 2012
‣ We need to write an application that solves buissiness problems
‣ We want to use OOP‣ We need to find a good design:
The problem
Thursday, March 1, 2012
‣ 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
The problem
Thursday, March 1, 2012
‣ 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
The problem
Thursday, March 1, 2012
‣ 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
The problem
Thursday, March 1, 2012
Thursday, March 1, 2012
Domain Model ?
Thursday, March 1, 2012
Domain Model ?
Thursday, March 1, 2012
‣ The domain model offers a simplified, abstract view of the problem
Domain Model
Domain Model
Thursday, March 1, 2012
‣ The domain model offers a simplified, abstract view of the problem
Domain Model
Domain Model
Domain Experts
Thursday, March 1, 2012
‣ The domain model offers a simplified, abstract view of the problem
Domain Model
Domain Model
Domain Experts
Implementators
Thursday, March 1, 2012
‣ The domain model offers a simplified, abstract view of the problem
Domain Model
Domain Model
Domain Experts
Implementators
Thursday, March 1, 2012
‣ The domain model offers a simplified, abstract view of the problem
Domain Model
Domain Model
Domain Experts
Implementators
Knowledge Crunching & Analysis
Thursday, March 1, 2012
‣ The domain model offers a simplified, abstract view of the problem
Domain Model
Domain Model
Domain Experts
Implementators
Knowledge Crunching & Analysis
Thursday, March 1, 2012
‣ a common language should be used to describe the problem
Domain Model
Domain Model
Domain Experts
Implementators
Ubiquitous Domain Language
Uses termsBoth understand
Thursday, March 1, 2012
‣ a common language should be used to describe the problem
Domain Model
Domain Model
Domain Experts
Implementators
Ubiquitous Domain Language
Uses termsBoth understand
Thursday, March 1, 2012
‣ The Domain Model can be represented as Text, Speech or Code...
Domain Model
Domain Model
Thursday, March 1, 2012
‣ The Domain Model can be represented as Text, Speech or Code...
Domain Model
Domain Model
Text
A customer can have multiple contracts. The customer gets monthly bills to his
billing address.
Thursday, March 1, 2012
‣ The Domain Model can be represented as Text, Speech or Code...
Domain Model
Domain Model
Text
UML
A customer can have multiple contracts. The customer gets monthly bills to his
billing address.
Thursday, March 1, 2012
‣ The Domain Model can be represented as Text, Speech or Code...
Domain Model
Domain Model
Text
UML
A customer can have multiple contracts. The customer gets monthly bills to his
billing address.
Code
Thursday, March 1, 2012
Thursday, March 1, 2012
UML
Thursday, March 1, 2012
•UML is perfect to describe, scetch or discuss a domain model.
UML
UML
Structural Diagrams Behavioral Diagrams
Class Diagrams Object Diagrams Sequence Diagrams Use Case Diagram ......
Thursday, March 1, 2012
UML - Class Diagram
Thursday, March 1, 2012
‣ class diagram describes the attributes and operations of a class and also the constraints imposed on the system.
UML - Class Diagram
Thursday, March 1, 2012
‣ 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)
UML - Class Diagram
Thursday, March 1, 2012
‣ 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“)
UML - Class Diagram
Thursday, March 1, 2012
‣ classes with:‣ attributes (<name>:<type> )‣methods ‣ annotations and properties
‣ Associations‣Multiplicity, roles‣ Traversal‣Aggregation, Composition
‣ Inheritance, Dependency‣ Qualifier ‣ Association Class
UML - Class Diagram - Examples
Thursday, March 1, 2012
‣ Depend on class diagrams‣ „Snapshot“ of instances and theire relations‣ Perfect to understand object behaviour and their
relationship from practical perspective
UML - Object Diagram
Thursday, March 1, 2012
‣ 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
UML - Sequence Diagram
Thursday, March 1, 2012
Thursday, March 1, 2012
Domain Driven DesignBasics
Thursday, March 1, 2012
1. Layered Architecture2. Common Building Blocks and Rules3. Find a „supple design“4. See the big picture
Domain Driven Design - Basics
Thursday, March 1, 2012
DDD - Layered Architecture
Thursday, March 1, 2012
DDD - Layered Architecture
Infrastructure / SystemLogging
PersitenceSpeaking to Webservices
File Formats
Thursday, March 1, 2012
DDD - Layered Architecture
Domain Model
Infrastructure / SystemLogging
PersitenceSpeaking to Webservices
File Formats
Core Business Logic
Thursday, March 1, 2012
DDD - Layered Architecture
Domain Model
Application Layer (thin)
Infrastructure / SystemLogging
PersitenceSpeaking to Webservices
File Formats
Core Business Logic
Controller / (Export/Import)
Thursday, March 1, 2012
DDD - Layered Architecture
Domain Model
Application Layer (thin)
Infrastructure / SystemLogging
PersitenceSpeaking to Webservices
File Formats
Core Business Logic
Controller / (Export/Import)User / Other Apps
Thursday, March 1, 2012
DDD - Layered Architecture
Domain Model
Application Layer (thin)
View
Infrastructure / SystemLogging
PersitenceSpeaking to Webservices
File Formats
Core Business Logic
Controller / (Export/Import)
Templates / Presentation Objects
User / Other Apps
Thursday, March 1, 2012
Thursday, March 1, 2012
Building Blocks
Thursday, March 1, 2012
Building Blocks
Thursday, March 1, 2012
DDD - Building Blocks
Thursday, March 1, 2012
DDD - Building Blocks
Entities
Thursday, March 1, 2012
DDD - Building Blocks
Entities
Values
Thursday, March 1, 2012
DDD - Building Blocks
Entities
Values
Services
Thursday, March 1, 2012
DDD - Building Blocks
Entities
Values
Services
Repository
Thursday, March 1, 2012
DDD - Building Blocks
Entities
Values
Services
Repository
Factory
Thursday, March 1, 2012
DDD - Building Blocks
Thursday, March 1, 2012
DDD - Building Blocks
Entities
Thursday, March 1, 2012
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
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
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
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
DDD - Building Blocks
Thursday, March 1, 2012
DDD - Building Blocks
Value
Thursday, March 1, 2012
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
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
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
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
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
DDD - Building Blocks
Thursday, March 1, 2012
DDD - Building Blocks
Service
Thursday, March 1, 2012
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
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
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
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
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
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 layersExamples: FundTransferService / PackageRoutingService / SimCardActivationService
Thursday, March 1, 2012
DDD - Building Blocks
Thursday, March 1, 2012
DDD - Building Blocks
Repository
Thursday, March 1, 2012
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
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
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
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
DDD - Building Blocks
Thursday, March 1, 2012
DDD - Building Blocks
Factory
Thursday, March 1, 2012
DDD - Building Blocks
Factory
A factory hides logic for building objects - this is especially relevant for aggregates!
Thursday, March 1, 2012
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
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
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
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
Thursday, March 1, 2012
Find a Supple Design
Thursday, March 1, 2012
Find a Supple Design
vs.
Thursday, March 1, 2012
Supple Design „Speak in Domain Language“
Thursday, March 1, 2012
‣ Try to explain scenarios loud with the use of the model and the ubiquitous language
Supple Design „Speak in Domain Language“
Thursday, March 1, 2012
‣ 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.
Supple Design „Speak in Domain Language“
Thursday, March 1, 2012
Supple Design „Reduce Associations“
Thursday, March 1, 2012
‣ Avoid many association and use only a minimum of relations because they decrease maintainability!
Supple Design „Reduce Associations“
Thursday, March 1, 2012
‣ Avoid many association and use only a minimum of relations because they decrease maintainability!
‣ traversal instead of bidirectional
Supple Design „Reduce Associations“
Thursday, March 1, 2012
‣ 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?)
Supple Design „Reduce Associations“
Thursday, March 1, 2012
‣ 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.
Supple Design „Reduce Associations“
Thursday, March 1, 2012
‣ 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
Supple Design „Reduce Associations“
Thursday, March 1, 2012
‣ 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
Supple Design „Reduce Associations“
Thursday, March 1, 2012
‣ 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 ...
Supple Design „Reduce Associations“
Thursday, March 1, 2012
Supple Design - Aggregates
Thursday, March 1, 2012
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
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
Supple Design - „Explicit constrains“
Thursday, March 1, 2012
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
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
Supple Design - „Specifications“
Thursday, March 1, 2012
Supple Design - „Specifications“
‣ you can use „Specifications“ to explicit express rules
Thursday, March 1, 2012
Supple Design - „Specifications“
‣ you can use „Specifications“ to explicit express rules
examples:
Thursday, March 1, 2012
Supple Design - „Specifications“
‣ you can use „Specifications“ to explicit express rules
examples:„InventoryDelinquentSpecification“->isSatisfied()
Thursday, March 1, 2012
Supple Design - „Specifications“
‣ you can use „Specifications“ to explicit express rules
examples:„InventoryDelinquentSpecification“->isSatisfied()„GoldenCustomerSpecification“->isSatisfied($customer)
Thursday, March 1, 2012
Supple Design - Modules
If your model tells a story a module is a chapterThursday, March 1, 2012
Supple Design - Modules
Customer Order
Product
Customer Contract Basket Order
OrderItems
AbstractProduct
Prepaid
Thursday, March 1, 2012
Supple Design - Modules
Customer Order
Product
Customer Contract Basket Order
OrderItems
AbstractProduct
Prepaid
• group by meaning in the domain
Thursday, March 1, 2012
Supple Design - Modules
Customer Order
Product
Customer Contract Basket Order
OrderItems
AbstractProduct
Prepaid
• group by meaning in the domain• loose coupling between modules
Thursday, March 1, 2012
Supple Design - What else
Thursday, March 1, 2012
Supple Design - What else
• Intention Revalving Interfaces
Thursday, March 1, 2012
Supple Design - What else
• Intention Revalving Interfaces• standalone classes where possible
Thursday, March 1, 2012
Supple Design - What else
• Intention Revalving Interfaces• standalone classes where possible• closure of operations
Thursday, March 1, 2012
Supple Design - What else
• Intention Revalving Interfaces• standalone classes where possible• closure of operations• side effect free functions
Thursday, March 1, 2012
Thank you for great year!
Thursday, March 1, 2012
Thank you for great year!Thanks
Thursday, March 1, 2012
top related