• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Domain Driven Design
 

Domain Driven Design

on

  • 1,409 views

Short Domain Driven Design and UML Refresher

Short Domain Driven Design and UML Refresher

Statistics

Views

Total Views
1,409
Views on SlideShare
1,408
Embed Views
1

Actions

Likes
2
Downloads
45
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Domain Driven Design Domain Driven Design Presentation Transcript

    • Thursday, March 1, 2012
    • Domain Driven Design short Refresher FLOW3 Usergroup @AOE by Daniel PötzingerThursday, March 1, 2012
    • Thursday, 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 find 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 find 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 find a good design: ‣ understanding the problem and the buissiness ‣ find 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 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
    • Thursday, March 1, 2012
    • Domain Model ?Thursday, March 1, 2012
    • Domain Model ?Thursday, March 1, 2012
    • Domain Model ‣ The domain model offers a simplified, abstract view of the problem Domain ModelThursday, March 1, 2012
    • Domain Model ‣ The domain model offers a simplified, abstract view of the problem Domain Experts Domain ModelThursday, March 1, 2012
    • Domain Model ‣ The domain model offers a simplified, abstract view of the problem Domain Experts Domain Model ImplementatorsThursday, March 1, 2012
    • Domain Model ‣ The domain model offers a simplified, abstract view of the problem Domain Experts Domain Model ImplementatorsThursday, March 1, 2012
    • Domain Model ‣ The domain model offers a simplified, abstract view of the problem Domain Experts Knowledge Crunching Domain Model & Analysis ImplementatorsThursday, March 1, 2012
    • Domain Model ‣ The domain model offers a simplified, 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 ‣ 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
    • Thursday, 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 ‣ Qualifier ‣ 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 „fulfill“ a use-case. ‣ useful to detect weakness and improvements in your designThursday, March 1, 2012
    • Thursday, 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
    • Thursday, March 1, 2012
    • Building BlocksThursday, 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 BlocksThursday, March 1, 2012
    • DDD - Building Blocks EntitiesThursday, 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 valueThursday, 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 livecycleThursday, 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 cycleThursday, March 1, 2012
    • DDD - Building BlocksThursday, 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 BlocksThursday, 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 • defined 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 • defined 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 • defined in common domain language • do not mix with other layers Examples: FundTransferService / PackageRoutingService / SimCardActivationServiceThursday, March 1, 2012
    • DDD - Building BlocksThursday, 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 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 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 find*() •find* methods communicate design decisions about how to access the data • ..reconstitution?Thursday, March 1, 2012
    • DDD - Building BlocksThursday, 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
    • 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 (find easier ways to say what you need to say). => That helps refining 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 qualifier 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 qualifier 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 qualifier to reduce multiplicity (class missing?) ‣ eliminate non essential assoc. ‣ find 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 qualifier to reduce multiplicity (class missing?) ‣ eliminate non essential assoc. ‣ find 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 qualifier to reduce multiplicity (class missing?) ‣ eliminate non essential assoc. ‣ find 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 „Specifications“ to explicit express rulesThursday, 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 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