Domain Driven Design

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

The problem that we want to
solve

The problem

‣ We need to write an application that solves
buissiness problems
The problem

buissiness problems
‣ We want to use OOP
The problem

buissiness problems
‣ We need to ﬁnd a good design:
The problem

buissiness problems
‣ understanding the problem and the buissiness
The problem

buissiness problems
‣ ﬁnd understandable class-structure
The problem

buissiness problems
‣ ﬁnd understandable class-structure
‣ build maintainable software, that can be adjusted
easy when the buissiness changes
The problem

Domain Model ?

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

the problem
Domain Model
Domain Model
Domain Experts

the problem
Domain Model
Domain Model
Domain Experts
Implementators

the problem
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 terms
Both understand

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

or Code...
Domain Model
Domain Model
Text
A customer can have multiple contracts.
The customer gets monthly bills to his
billing address.

or Code...
Domain Model
Domain Model
Text
UML
billing address.

or Code...
Domain Model
Domain Model
Text
UML
billing address.
Code

•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
‣ Qualiﬁer
‣ 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
„fulﬁll“ a use-case.
‣ useful to detect weakness and improvements in your
design
UML - Sequence Diagram

Domain Driven Design
Basics

1. Layered Architecture
2. Common Building Blocks and Rules
3. Find a „supple design“
4. See the big picture
Domain Driven Design - Basics

DDD - Layered Architecture

Infrastructure / System
Logging
Persitence
Speaking to Webservices
File Formats

Domain Model
Logging
Persitence
File Formats
Core Business Logic

Domain Model
Application Layer (thin)
Logging
Persitence
File Formats
Core Business Logic
Controller / (Export/Import)

Domain Model
Logging
Persitence
File Formats
Core Business Logic
Controller / (Export/Import)User /
Other Apps

Domain Model
View
Logging
Persitence
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
Object which is primary deﬁned by its identity (not by
attributes). For example "Person", "Car", "Costumer" or
"BankTransaction".

Entities
"BankTransaction".
• often has some ID value

Entities
"BankTransaction".
• continuity through livecycle

Entities
"BankTransaction".
• continuity through livecycle
• keep class deﬁnition 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
address, color ...
• should represent a whole value (conceptual thing )

Value
address, color ...
• Often passed as arguments

Value
address, color ...
• No Identity gives freedom

Value
address, color ...
• 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
objects
• deﬁned in common domain language

Service
• stateless
objects
• do not mix with other layers

Service
• stateless
objects
• do not mix with other layers
Examples: 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 ﬁnd*()

Repository
•ﬁnd* methods communicate design decisions about how to
access the data

Repository
•ﬁnd* 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
• not allowed to give wrong results (exceptions)

Factory
• entity vs. value factories

Factory
• 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 (ﬁnd easier
ways to say what you need to say).
=> That helps reﬁning the model.

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

=> 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 „Speciﬁcations“ to explicit express rules

examples:

examples:
„InventoryDelinquentSpeciﬁcation“->isSatisﬁed()

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

Supple Design - Modules
If your model tells a story a module is a chapter

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

• standalone classes where possible

• closure of operations

• closure of operations
• side effect free functions

Thank you for great year!

Thank you for great year!
Thanks

Domain Driven Design

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Domain Driven Design

Ähnlich wie Domain Driven Design (20)

Mehr von AOE

Mehr von AOE (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Domain Driven Design