domain driven design

Thursday, March 1, 2012

Domain Driven Designshort Refresher

FLOW3 Usergroup @AOEby Daniel Pötzinger


The problem that we want to solve


The problem


‣ We need to write an application that solves buissiness problems

The problem



‣ We want to use OOP

The problem



‣ We want to use OOP‣ We need to find a good design:

The problem



‣ We want to use OOP‣ We need to find a good design:‣ understanding the problem and the buissiness

The problem



‣ We want to use OOP‣ We need to find a good design:‣ understanding the problem and the buissiness‣ find understandable class-structure

The problem



‣ 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


Domain Model ?


‣ The domain model offers a simplified, abstract view of the problem

Domain Model

Domain Model



Domain Model

Domain Model

Domain Experts



Domain Model

Domain Model

Domain Experts

Implementators



Domain Model

Domain Model

Domain Experts

Implementators

Knowledge Crunching & Analysis


‣ a common language should be used to describe the problem

Domain Model

Domain Model

Domain Experts

Implementators

Ubiquitous Domain Language

Uses termsBoth understand


‣ The Domain Model can be represented as Text, Speech or Code...

Domain Model

Domain Model



Domain Model

Domain Model

Text

A customer can have multiple contracts. The customer gets monthly bills to his

billing address.



Domain Model

Domain Model

Text

UML


billing address.



Domain Model

Domain Model

Text

UML


billing address.

Code


UML


•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 ......


UML - Class Diagram


‣ class diagram describes the attributes and operations of a class and also the constraints imposed on the system.

UML - Class Diagram



‣ Can be directly mapped to code (OOP)

UML - Class Diagram



‣ 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


‣ classes with:‣ attributes (<name>:<type> )‣methods ‣ annotations and properties

‣ Associations‣Multiplicity, roles‣ Traversal‣Aggregation, Composition

‣ Inheritance, Dependency‣ Qualifier ‣ Association Class

UML - Class Diagram - Examples


‣ Depend on class diagrams‣ „Snapshot“ of instances and theire relations‣ Perfect to understand object behaviour and their

relationship from practical perspective

UML - Object 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

UML - Sequence Diagram


Domain Driven DesignBasics


1. Layered Architecture2. Common Building Blocks and Rules3. Find a „supple design“4. See the big picture

Domain Driven Design - Basics


DDD - Layered Architecture



Infrastructure / SystemLogging

PersitenceSpeaking to Webservices

File Formats



Domain Model



File Formats

Core Business Logic



Domain Model

Application Layer (thin)



File Formats

Core Business Logic

Controller / (Export/Import)



Domain Model




File Formats

Core Business Logic

Controller / (Export/Import)User / Other Apps



Domain Model


View



File Formats

Core Business Logic

Controller / (Export/Import)

Templates / Presentation Objects

User / Other Apps


Building Blocks


DDD - Building Blocks



Entities



Entities

Values



Entities

Values

Services



Entities

Values

Services

Repository



Entities

Values

Services

Repository

Factory



Entities



Entities

Object which is primary defined by its identity (not by attributes). For example "Person", "Car", "Costumer" or "BankTransaction".



Entities


• often has some ID value



Entities


• often has some ID value• continuity through livecycle



Entities


• often has some ID value• continuity through livecycle• keep class definition simple / focus on live cycle



Value



Value

describe the characteristic of a thing and identity is not required. (We care what they are - not who) Example: address, color ...



Value


• should represent a whole value (conceptual thing )



Value


• should represent a whole value (conceptual thing )• Often passed as arguments



Value


• should represent a whole value (conceptual thing )• Often passed as arguments• No Identity gives freedom



Value


• should represent a whole value (conceptual thing )• Often passed as arguments• No Identity gives freedom• should be Immutable!



Service



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."



Service


• stateless



Service


• stateless• offer a useful service or action and deals with other domain objects



Service


• stateless• offer a useful service or action and deals with other domain objects• defined in common domain language



Service


• stateless• offer a useful service or action and deals with other domain objects• defined in common domain language• do not mix with other layers



Service


• 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



Repository



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.



Repository


• typicaly methods for add() remove() and find*()



Repository


• typicaly methods for add() remove() and find*()•find* methods communicate design decisions about how to access the data



Repository


• typicaly methods for add() remove() and find*()•find* methods communicate design decisions about how to access the data• ..reconstitution?



Factory



Factory

A factory hides logic for building objects - this is especially relevant for aggregates!



Factory


• atomic (need to pass all essential parameters)



Factory


• atomic (need to pass all essential parameters)• not allowed to give wrong results (exceptions)



Factory


• atomic (need to pass all essential parameters)• not allowed to give wrong results (exceptions)• entity vs. value factories



Factory


• atomic (need to pass all essential parameters)• not allowed to give wrong results (exceptions)• entity vs. value factories• (can also be used for reconstitution )


Find a Supple Design


Find a Supple Design

vs.


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 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 „Reduce Associations“


‣ Avoid many association and use only a minimum of relations because they decrease maintainability!




‣ traversal instead of bidirectional




‣ traversal instead of bidirectional‣ adding qualifier to reduce multiplicity (class missing?)




‣ traversal instead of bidirectional‣ adding qualifier to reduce multiplicity (class missing?)‣ eliminate non essential assoc.




‣ traversal instead of bidirectional‣ adding qualifier to reduce multiplicity (class missing?)‣ eliminate non essential assoc.‣ find and use aggregates





=> Intuition and Refactoring





=> Intuition and Refactoring

... country / president example ...



Supple Design - Aggregates



‣ An aggregate is a group of objects that belong together (a group of individual objects that represents a unit)



‣ An aggregate is a group of objects that belong together (a group of individual objects that represents a unit)

‣ ...car example... (root, boundary, invariants )


Supple Design - „Explicit constrains“



‣ name and make constrains explicit. That gives it a name you can talk about and the code is more understandable



‣ name and make constrains explicit. That gives it a name you can talk about and the code is more understandable

Bucket example


Supple Design - „Specifications“



‣ you can use „Specifications“ to explicit express rules




examples:




examples:„InventoryDelinquentSpecification“->isSatisfied()




examples:„InventoryDelinquentSpecification“->isSatisfied()„GoldenCustomerSpecification“->isSatisfied($customer)


Supple Design - Modules

If your model tells a story a module is a chapterThursday, March 1, 2012


Customer Order

Product

Customer Contract Basket Order

OrderItems

AbstractProduct

Prepaid



Customer Order

Product


OrderItems

AbstractProduct

Prepaid

• group by meaning in the domain



Customer Order

Product


OrderItems

AbstractProduct

Prepaid

• group by meaning in the domain• loose coupling between modules


Supple Design - What else



• Intention Revalving Interfaces



• Intention Revalving Interfaces• standalone classes where possible



• Intention Revalving Interfaces• standalone classes where possible• closure of operations



• Intention Revalving Interfaces• standalone classes where possible• closure of operations• side effect free functions


Thank you for great year!


Thank you for great year!Thanks


domain driven design

Technology