Post on 14-Dec-2014
description
Domain Driven Design Eric Evans
(2004)
Domain Driven Design Eric Evans
(2004)
Clean Code (2008)
Domain Driven Design Eric Evans
(2004)
Clean Code (2008)
Extreme Programming (1999)
Domain Driven Design Eric Evans
(2004)
Goal
Give you the tools to develop good software for a client
T O P I C S C O V E R E D …
• Model-Driven Design
• DDD & Objects
• Clean Code
• Scaling Out
M O D E L - D R I V E N D E S I G NPA R T O N E
“rigorously organized and selective abstraction of what’s in the domain expert’s head”
A M O D E L I S N O T…
• Overly technical
• An indiscriminate minddump of domain knowledge
S A M P L E M O D E L ( F I N A N C E & R I S K )
R I S K FA C T O R S
S C E N A R I O S
D R I V E R S
P O R T F O L I O
A S S E T S
U B I Q U I T O U S L A N G U A G E
U B I Q U I T O U S L A N G U A G E
• Easier communication between developer & business
• Easier communication between developers!
• Improve ‘agility’
• Leads to better UX
D D D & O B J E C T SPA R T T W O
D ATA O B J E C T S
E N T I T I E S V S . VA L U E O B J E C T S
D A TA O B J E C T S
PA I N T P I G M E N T SVA L U E O B J E C T S
Z O O A N I M A L SE N T I T I E S
C O N T E X T- D E P E N D E N TW A R N I N G !
• N A M E • M E M B E R S
B A N D
• N A M E • M E M B E R S
B A N D
• N A M E • M E M B E R S
B A N D
• N A M E • M E M B E R S
B A N D
• N A M E • M E M B E R S
B A N D
• N A M E • M E M B E R S
B A N D
• N A M E • M E M B E R S
B A N D
• N A M E • M E M B E R S
B A N D
• N A M E • M E M B E R S
B A N D
“ D O I N G ” O B J E C T S
C O M M O N PAT T E R N S
• Factory
• Repositories
• Modules
“ S E R V I C E S ”
D O I N G O B J E C T S
“ S E R V I C E S ”
A C C O U N T 1 A C C O U N T 2
D E B I T ( £ 1 0 0 )
C R E D I T £ 1 0 0
“ S E R V I C E S ”
A C C O U N T 1 A C C O U N T 2
D E B I T ( £ 1 0 0 )
C R E D I T £ 1 0 0
T R A N S A C T I O N H A N D L E R
S A M P L E M O D E L ( F I N A N C E & R I S K )
R I S K FA C T O R S
S C E N A R I O S
D R I V E R S
P O R T F O L I O
A S S E T S
T H E C L A S S E S …
• Entites
• Value Objects
• Services
• Factories
• Repositories
C L E A N C O D EPA R T T H R E E
C O N C E P T I N G V S .
C O D I N G
R E A D C L E A N C O D EG O O D A D V I C E …
D E C L A R AT I V E I N T E R FA C E S
S TA N D A L O N E C L A S S E S
N O S I D E - E F F E C T S
A G G R E G AT E S
A G G R E G AT E S
• Root/Boundary
• Root has global identity
• Nothing outside boundary can hold reference to anything inside.
• Delete operation must remove everything within the boundary.
A G G R E G AT E S
C A R
T I R E S W H E E L D R I V E R
A G G R E G AT E S
C A R
T I R E S W H E E L D R I V E R
K E Y B A D S M E L L S
• Needing to look into implementations
• Large chains of dependencies
• Side Effects
• Worrying about relationships in entity state
S C A L I N G O U TPA R T F O U R
U B I Q U I T O U S M O D E L B E C O M E S F R A C T U R E D
T H E P R O B L E M
B O U N D E D C O N T E X T S
T H E S O L U T I O N
B O U N D E D C O N T E X T S
• Advertise through Context Maps
• Defend against unstable projects with facades
• Give up
C A N ’ T S E E T H E B I G G E R P I C T U R E
T H E P R O B L E M
D I S T I L L AT I O N
T H E S O L U T I O N
P R O B L E M S …
• ‘Distilation’ was a form of reducing documentation from 200-ish pages to 7 pages.
S A LVA G I N G D I S T I L L AT I O N
• Splitting out parts of your model into:
• Core Model
• Cohesive Mechanisms
• Generic
C O D E B A S E T O O L A R G E T O D E V E L O P W I T H
T H E P R O B L E M
L A R G E S C A L E S T R U C T U R E
S C A L I N G O U T
“Should be applied when a structure can be found that greatly clarifies the system without
forcing unnatural constraints on model development.”
P O S S I B L E “ L S S ” O P T I O N S
• System Metaphor
• Divide and Conquer
• Responsibility Layers
• Knowledge Level
• Pluggable Component Framework
C O N C L U S I O N
I S I T W O R T H R E A D I N G ?
I S I T W O R T H R E A D I N G ?all
T O P I C S C O V E R E D …
• Model-Driven Design
• DDD & Objects
• Clean Code
• Scaling Out
Q U E S T I O N S ?