Transcript Domain-driven design from theory to practice

Domain-driven design
from theory to practice
Artur Trosin
Presentation for: Software as Craft 2009, 14-16 May
Before start
Why DDD nowadays?
•
•
•
•
Automation of various business domains
High competition for a market place
Growing business complexity
Complexity becomes inevitable
Why DDD?
•
•
•
•
Accidental complexity is bad
DDD is OO done right
Semantics over technology
Is discovered and NOT invented
DDD benefits?
•
•
•
•
•
Reduced complexity
High maintainability
Continuous collaboration and feedback
Brings to front the “Core Domain Knowledge”
Translations are reduced to minimum
Domain - particular field of knowledge
Complexity of most software
projects is understanding the business
domain and not a technical one.
Domain Driven Design is based on
models.
Atom Model
Even Music has a Model
The key to controlling complexity is a
good domain model.
Martin Fowler
They are two different worlds!
Business Domain
(business experts)
We need to bring them together
(business domain & technical)
Software Development
(development team)
Successes depends on “how well you bring them together”
We need common view and language!
Business Domain
Domain Model
&
Ubiquities Language
Software
Development
Domain Model - is a rigorously
organized and selective abstraction of
the (Business) Domain knowledge.
Ubiquitous Language - A language
structured around the domain model
and used by all team members to
connect all the activities of the team
with the software.
Ubiquitous Language
Business terms
developers don’t
understand
Technical terms
Domain Model Terms
DDD Patterns
Business terms
everyone uses that
don’t appear in design
Candidates to fold into model
Bounded Contexts
Technical aspects
of design
Technical design
patterns
S.O.L.I.D design
principles
Collaboration
Domain Experts and Developers produce Model
Software
Development
Business Domain
Produce
Domain Model
&
Ubiquities Language
Direct mapping between business domain
concepts and software artifacts
Reflected in
Software
Based on
Building blocks
Classic Layering
UI
Business Entities
Data Access
DB
Record Sets or
Data Sets or
POCO or
POJO
DDD recommended-Layering
Presentation
Service Layer
Application
Domain
Infrastructure
Domain Model
Organizing Domain Logic Patterns
Transaction Script
Table Module
Effort
to enhance
Domain Model
Complexity of Domain Logic
Source : PoEAA by Martin Fowler
A model expressed in software with:
Modules
Model-Driven
Design
Access with
Services
Express model with
Express model with
Life Cycle of domain object controlled by:
Express model with
Repository
Maintain integrity with
Entities
Act as root of
Aggregates
Express model with
Value Objects
X
Mutually exclusive
choice
Smart UI
Access with
Encapsulate with
Isolate domain with
Encapsulate with
Encapsulate with
Layered
Architecture
Encapsulate with
Factories
Associations
Country
Country
Country
Period
President
*
Person
President
*
Person
President
Person
*
Entities
• An object defined primarily by its identity and
not its attributes
• Could be a person, a customer, an order, etc.
• Not all objects have meaningful identities…
• In some systems, a class may be an ENTITY, in
others maybe not
Value Objects
• Represent an aspect of the domain with NO
conceptual identity
• Use when you care about what something is,
not who they are
• Simple, immutable objects
• NOT is same thing as a DTO [Fowler PoEAA]
Services
• An operation offered as an interface that
stands alone in the model
• Does not fit into any of the objects in the
model
• Stateless
• To be used judiciously (do not turn your app
into a Transaction Script)
• Use when an operation is an important
domain concept
Modules
•
•
•
•
•
Is larger grain of modeling and design
A method of organized related concepts
Low coupling and high cohesion
Communications mechanism.
Could be Administration, Invoicing, Reports,…
Aggregates
• A cluster of associated objects that is treated
as a conceptual whole
• Define consistency boundaries
• A unit for the purpose of data changes
• Is controlled by root
Factories
• Shifts complicated object creation to FACTORY
• Enforce invariants
• Decouple clients and hide creation details
Repositories
• Provide illusion of an in-memory collection
• Provide a simple model for obtaining
persistent objects
• Decouple domain model from persistence
technology
• Communicate design decisions about object
access
• IS NOT just DAO with CRUD
Cargo Sample
C# version - http://code.google.com/p/ndddsample
Java version - http://dddsample.sourceforge.net/
Collaboration: gathering requirements
1. As a Customer I would like to Book Cargo in
advance in order to transport it to Destination
2. As a Cargo owner I would like to Track Cargo
handling using a key, in order to
see Handling History
Find, Filter and Highlight the “Core”
Model Evolution: Step 1
Cargo
• Tracking Id
Route Specification
• Origin Location
• Destin Location
Itineraries
*
Leg
• Load Location
• Un-Load Location
Voyage
• Voyage Number
• Schedule
Model Evolution: Step 2
Cargo
• Tracking Id
Origin
Route Specification
• Arrival Deadline Time
Destination
Location
• UnLocode
Itinerary
*
Leg
• Load Time
• Unload Time
Load
Un-Load
1. Make Itinerary and Location explicit
2. Discover that Location is identified by United Nations Code for
Trade and Transport Locations
1. Add Arrival Deadline to Route Specification
2. Add Load/Unload Time to Leg
Voyage
• Voyage Number
• Schedule
*
Handling History
Cargo
• Tracking Id
Handling Event
Event Location
• Handling Type
• Completion Time
Origin
Route Specification
• Arrival Deadline Time
Destination
Location
• UnLocode
0..1
Itinerary
*
Leg
• Load Time
• Unload Time
Load
Un-Load
1. Discover that Itinerary could be assigned later
2. Add Handling Event: Handling Type{Load, Unload}
3. Add Handling History: to track handling events for a Cargo
Voyage
• Voyage Number
• Schedule
VO
AR
Handling History
*
Handling Event
Cargo
Event Location
• Handling Type
• Completion Time
Entity
AR
STOP : Select Repositories!
Entity
VO
Origin
Route Specification
• Tracking Id
• Arrival Deadline Time
Destination
AR
0..1
Itinerary
VO- Value Object
Entity
AR-Aggregate Root
*
Entity
• UnLocode
VO
VO
Location
Leg
• Load Time
• Unload Time
Load
AR
Voyage
• Voyage Number
• Schedule
Entity
Cargo’s Ubiquitous Language
Cargo
Handling Event
Route Specification
Cargo Tracking
Handling History
Itinerary
Tracking Id
Location
Voyage
Cargo Booking
Leg
Cargo Tracking
Itinerary
Domain Model Isolation
Presentation
Application
Domain
Infrastructure
Separated Interface Pattern
Presentation
Application
Domain
Infrastructure Persistence
Infrastructure
How about design principles &
patterns within Domain Layer?
DDD doesn’t ignore Design Principles OR Design
Patterns
S.O.L.I.D.,… Design Principles
Strategy, Composite, Specification,… Design Patterns
Specification
- Makes the model more explicit
- Allow to Compose
- Could be used with:
1. Repositories - to specify Queries
2. Factories – to specify Object Creation
requirements
3. For validation
Real Sample
Cargo
• Tracking Id
0..1
Itinerary
Usage:
Route Specification
Origin
• Arrival Deadline Time
Location
• UnLocode
Destination
Strategy (a.k.a Policy)
Define a family of algorithms, encapsulate
each one, and make them interchangeable.
Strategy lets the algorithm vary independently
from clients that use it.
Strategy
Context
• +ContextInterface()
• +AlgoritmInterface()
ConcreateStrategyA
ConcreateStrategyB
ConcreateStrategyB
• +AlgoritmInterface()
• +AlgoritmInterface()
• +AlgoritmInterface()
Refactoring to Policy
LegMagnitudePolicy
• +Length(Leg leg): double
LegTimeMagnitude
• +Length(Leg leg)
LegMoneyMagnitude
• +Length(Leg leg)
Requirement: 1. Book cargo in advance
Service\Façade Pattern
Presentation
Application
Domain
Infrastructure
Application Services act Use Case
Scenarios
Expose to External World
DTO\Remote Façade\Transfer
Assembler Patterns
Presentation
Application
Domain
Infrastructure
RMI or WCF Services
MVC & Remote Facade
TO BE DEFINED
MVC & Domain Model
TO BE DEFINED
Tools and Frameworks
•
•
•
•
IoC & DI containers
AOP frameworks
ORMs
Mocking Frameworks
Agile Practices
• Iterative Development
• Developers and domain experts have close
relationship
• TDD & PI
• Continuous Refactoring
• Continuous Integration
DDD Anti-patterns
• Anemic Domain Model
• Big Design Up-Front (BDUF)
References
• Domain-Driven Design: Tackling Complexity in the
Heart of Software
• Domain Driven Design Quickly
• Applying Domain-Driven Design and Patterns: With
Examples in C# and .NET
• Patterns of Enterprise Application Architecture
• .NET Domain-Driven Design with C#: Problem - Design
– Solution
• Cargo DDD Application Sample – C# implementation/
Java implementation
• My Blog Post - Domain Driven Design: Learning
• My e-mail [email protected] 
Finally{}
Thank you
Questions?