Domain Driven Design

Thursday, March 1, 2012

Domain Driven Design short Refresher FLOW3 Usergroup @AOE by Daniel PötzingerThursday, March 1, 2012

The problem that we want to solveThursday, March 1, 2012

The problemThursday, March 1, 2012

The problem ‣ We need to write an application that solves buissiness problemsThursday, March 1, 2012

The problem ‣ We need to write an application that solves buissiness problems ‣ We want to use OOPThursday, March 1, 2012

The problem ‣ We need to write an application that solves buissiness problems ‣ We want to use OOP ‣ We need to ﬁnd a good design:Thursday, March 1, 2012

The problem ‣ We need to write an application that solves buissiness problems ‣ We want to use OOP ‣ We need to ﬁnd a good design: ‣ understanding the problem and the buissinessThursday, March 1, 2012

The problem ‣ We need to write an application that solves buissiness problems ‣ We want to use OOP ‣ We need to ﬁnd a good design: ‣ understanding the problem and the buissiness ‣ ﬁnd understandable class-structureThursday, March 1, 2012

The problem ‣ We need to write an application that solves buissiness problems ‣ We want to use OOP ‣ We need to ﬁnd a good design: ‣ understanding the problem and the buissiness ‣ ﬁnd understandable class-structure ‣ build maintainable software, that can be adjusted easy when the buissiness changesThursday, March 1, 2012

Domain Model ?Thursday, March 1, 2012

Domain Model ‣ The domain model offers a simpliﬁed, abstract view of the problem Domain ModelThursday, March 1, 2012

Domain Model ‣ The domain model offers a simpliﬁed, abstract view of the problem Domain Experts Domain ModelThursday, March 1, 2012

Domain Model ‣ The domain model offers a simpliﬁed, abstract view of the problem Domain Experts Domain Model ImplementatorsThursday, March 1, 2012

Domain Model ‣ The domain model offers a simpliﬁed, abstract view of the problem Domain Experts Knowledge Crunching Domain Model & Analysis ImplementatorsThursday, March 1, 2012

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

Domain Model ‣ The Domain Model can be represented as Text, Speech or Code... Domain ModelThursday, March 1, 2012

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

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

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

UMLThursday, March 1, 2012

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

UML - Class DiagramThursday, March 1, 2012

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

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

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

UML - Class Diagram - Examples ‣ classes with: ‣ attributes (<name>:<type> ) ‣ methods ‣ annotations and properties ‣ Associations ‣ Multiplicity, roles ‣ Traversal ‣ Aggregation, Composition ‣ Inheritance, Dependency ‣ Qualiﬁer ‣ Association ClassThursday, March 1, 2012

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

UML - Sequence Diagram ‣ Depend on class diagrams ‣ Perfect to explain how objects work together to „fulﬁll“ a use-case. ‣ useful to detect weakness and improvements in your designThursday, March 1, 2012

Domain Driven Design BasicsThursday, March 1, 2012

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

DDD - Layered ArchitectureThursday, March 1, 2012

DDD - Layered Architecture Logging Persitence Infrastructure / System Speaking to Webservices File FormatsThursday, March 1, 2012

DDD - Layered Architecture Domain Model Core Business Logic Logging Persitence Infrastructure / System Speaking to Webservices File FormatsThursday, March 1, 2012

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

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

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

Building BlocksThursday, March 1, 2012

DDD - Building BlocksThursday, March 1, 2012

DDD - Building Blocks EntitiesThursday, March 1, 2012

DDD - Building Blocks Entities ValuesThursday, March 1, 2012

DDD - Building Blocks Entities Values ServicesThursday, March 1, 2012

DDD - Building Blocks Entities Repository Values ServicesThursday, March 1, 2012

DDD - Building Blocks Entities Repository Values Factory ServicesThursday, March 1, 2012

DDD - Building Blocks EntitiesThursday, March 1, 2012

DDD - Building Blocks Entities Object which is primary deﬁned 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 deﬁned by its identity (not by attributes). For example "Person", "Car", "Costumer" or "BankTransaction". • often has some ID valueThursday, March 1, 2012

DDD - Building Blocks Entities Object which is primary deﬁned by its identity (not by attributes). For example "Person", "Car", "Costumer" or "BankTransaction". • often has some ID value • continuity through livecycleThursday, March 1, 2012

DDD - Building Blocks Entities Object which is primary deﬁned by its identity (not by attributes). For example "Person", "Car", "Costumer" or "BankTransaction". • often has some ID value • continuity through livecycle • keep class deﬁnition simple / focus on live cycleThursday, March 1, 2012

DDD - Building Blocks ValueThursday, 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 argumentsThursday, 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 freedomThursday, 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 ServiceThursday, 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." • statelessThursday, 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 objectsThursday, 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 • deﬁned in common domain languageThursday, 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 • deﬁned in common domain language • do not mix with other layersThursday, 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 • deﬁned in common domain language • do not mix with other layers Examples: FundTransferService / PackageRoutingService / SimCardActivationServiceThursday, March 1, 2012

DDD - Building Blocks RepositoryThursday, 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 ﬁnd*()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 ﬁnd*() •ﬁnd* methods communicate design decisions about how to access the dataThursday, 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 ﬁnd*() •ﬁnd* methods communicate design decisions about how to access the data • ..reconstitution?Thursday, March 1, 2012

DDD - Building Blocks FactoryThursday, 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 factoriesThursday, 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

Find a Supple DesignThursday, March 1, 2012

Find a Supple Design vs.Thursday, March 1, 2012

Supple Design „Speak in Domain Language“Thursday, March 1, 2012

Supple Design „Speak in Domain Language“ ‣ Try to explain scenarios loud with the use of the model and the ubiquitous languageThursday, March 1, 2012

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 (ﬁnd easier ways to say what you need to say). => That helps reﬁning the model.Thursday, March 1, 2012

Supple Design „Reduce Associations“Thursday, March 1, 2012

Supple Design „Reduce Associations“ ‣ Avoid many association and use only a minimum of relations because they decrease maintainability!Thursday, March 1, 2012

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

Supple Design „Reduce Associations“ ‣ Avoid many association and use only a minimum of relations because they decrease maintainability! ‣ traversal instead of bidirectional ‣ adding qualiﬁer to reduce multiplicity (class missing?)Thursday, March 1, 2012

Supple Design „Reduce Associations“ ‣ Avoid many association and use only a minimum of relations because they decrease maintainability! ‣ traversal instead of bidirectional ‣ adding qualiﬁer to reduce multiplicity (class missing?) ‣ eliminate non essential assoc.Thursday, March 1, 2012

Supple Design „Reduce Associations“ ‣ Avoid many association and use only a minimum of relations because they decrease maintainability! ‣ traversal instead of bidirectional ‣ adding qualiﬁer to reduce multiplicity (class missing?) ‣ eliminate non essential assoc. ‣ ﬁnd and use aggregatesThursday, March 1, 2012

Supple Design „Reduce Associations“ ‣ Avoid many association and use only a minimum of relations because they decrease maintainability! ‣ traversal instead of bidirectional ‣ adding qualiﬁer to reduce multiplicity (class missing?) ‣ eliminate non essential assoc. ‣ ﬁnd and use aggregates => Intuition and RefactoringThursday, March 1, 2012

Supple Design „Reduce Associations“ ‣ Avoid many association and use only a minimum of relations because they decrease maintainability! ‣ traversal instead of bidirectional ‣ adding qualiﬁer to reduce multiplicity (class missing?) ‣ eliminate non essential assoc. ‣ ﬁnd and use aggregates => Intuition and Refactoring ... country / president example ...Thursday, March 1, 2012

Supple Design - AggregatesThursday, 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 understandableThursday, 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 exampleThursday, March 1, 2012

Supple Design - „Specifications“Thursday, March 1, 2012

Supple Design - „Specifications“ ‣ you can use „Speciﬁcations“ to explicit express rulesThursday, March 1, 2012

Supple Design - „Specifications“ ‣ you can use „Speciﬁcations“ 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 Customer Contract Basket Order OrderItems Product AbstractProduct PrepaidThursday, March 1, 2012

Supple Design - Modules Customer Order Customer Contract Basket Order OrderItems Product AbstractProduct • group by meaning in the domain PrepaidThursday, March 1, 2012

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

Supple Design - What elseThursday, March 1, 2012

Supple Design - What else • Intention Revalving InterfacesThursday, March 1, 2012

Supple Design - What else • Intention Revalving Interfaces • standalone classes where possibleThursday, March 1, 2012

Supple Design - What else • Intention Revalving Interfaces • standalone classes where possible • closure of operationsThursday, March 1, 2012

Supple Design - What else • Intention Revalving Interfaces • standalone classes where possible • closure of operations • side effect free functionsThursday, March 1, 2012

Thank you for great year!Thursday, March 1, 2012

Thank you for great year! ThanksThursday, March 1, 2012

Domain Driven Design

by AOE media

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

Domain Driven Design Presentation Transcript