2. Domain Driven Design
• Status
Quo
of
building
Enterprise
Applica;ons
(EA)
• What
is
DDD?
• Strategic
DDD
• Tac;cal
DDD
(a.k.a.
DDD-‐Lite)
• Code
/
Example
• Ques;ons
• Resources
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 2
3. Status Quo of building Enterprise
Applications (EA)
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
4. Status Quo of building EA
• How
would
you
build
an
EA?
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 4
5. Status Quo of building EA
• How
would
you
build
an
EA?
– Layered
Architecture
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 5
Persistence
Domain
Presenta;on
6. Status Quo of building EA
• How
would
you
build
an
EA?
– Layered
Architecture
• Domain
Layer:
How
to
organize
it?
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 6
Persistence
Domain
Presenta;on
7. Status Quo of building EA
• How
would
you
build
an
EA?
– Layered
Architecture
• Domain
Layer:
How
to
organize
it?
• Three
Standard
PaPerns
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 7
Persistence
Domain
Presenta;on
8. Status Quo of building EA
• Transac;on
Script
– Express
business
logic
via
procedures
– Easy
to
grasp
and
to
avoid
performance
problems
• Domain
Model
– Object
model
of
domain,
having
both
–
behaviour
and
data
– Expressive
but
elaborated
• Table
Module
– middle
ground
between
the
two
above
– one
class
per
db
table
with
procedures
over
the
data
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 8
Persistence
Domain
Presenta;on
9. Status Quo of building EA
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 9
Source:
[Fowler,
PoEAA]
10. Status Quo of building EA
• How
Spring
MVC
does
the
work?
• The
result:
– Thinking
in
technical
terms,
not
domain’s
one
– Anemic
Domain
Model
(POJO’s
with
no
behaviour)
– Boilerplate
Services
layer
with
too
many
responsibili;es
– No
separa;on
of
(domain)
concerns
• Accept
it
my
friend,
it’s
pure
Transac;on
Script
in
ac;on!
– i.e.
Procedural
Programming
disguised
as
OOP
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 10
Controller
Service
DAO
DTO
12. What is DDD?
• What
is
DDD?
– Not
a
Technology
or
Methodology
– Set
of
principles
and
paPerns
for
focusing
the
design
effort
where
it
maPers
most
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 12
13. What is DDD?
• What
is
DDD?
– Not
a
Technology
or
Methodology
– Set
of
principles
and
paPerns
for
focusing
the
design
effort
where
it
maPers
most
• It’s
all
about…
– Understanding
of
the
domain
(subject
area)
where
the
soaware
will
be
applied
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 13
HOW
DOES
IT
WORK?
14. What is DDD?
• What
is
DDD?
– Not
a
Technology
or
Methodology
– Set
of
principles
and
paPerns
for
focusing
the
design
effort
where
it
maPers
most
• It’s
all
about…
– Understanding
of
the
domain
(subject
area)
where
the
soaware
will
be
applied
– Create
highly
expressive
model
of
that
domain
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 14
HOW
DOES
IT
WORK?
BUILD
A
MODEL
15. What is DDD?
• What
is
DDD?
– Not
a
Technology
or
Methodology
– Set
of
principles
and
paPerns
for
focusing
the
design
effort
where
it
maPers
most
• It’s
all
about…
– Understanding
of
the
domain
(subject
area)
where
the
soaware
will
be
applied
– Create
highly
expressive
model
of
that
domain
– Dis;l
Ubiquitous
Language
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 15
HOW
DOES
IT
WORK?
BUILD
A
MODEL
GROW
A
LANGUAGE
16. What is a Model?
• What
is
a
Model?
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 16
17. What is a Model?
• What
is
a
Model?
– Simplifica;on
of
reality
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 17
18. What is a Model?
• What
is
a
Model?
– Simplifica;on
of
reality
– Shows
some
aspect
of
reality…
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 18
19. What is a Model?
• What
is
a
Model?
– Simplifica;on
of
reality
– Shows
some
aspect
of
reality…
– …
or
an
idea
that
is
of
interest
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 19
20. What is a Model?
• How
do
you
represent
your
Model?
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 20
(UML)
DIAGRAMS?
21. What is a Model?
• How
do
you
represent
your
Model?
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 21
TEXT?
Ingest
engineer
manages
brands
As
an
ingest
engineer
I
want
to
ingest
brands,
series
and
episodes
So
that
users
could
browse
them
Scenario
1:
Episodes
IngesKon
Given
a
brand
with
one
series
When
I
ingest
an
episode
Then
its
gets
ready
for
to
be
seen
Scenario
2:
Episodes
are
seen
Given
a
brand
with
1
series
and
an
episode
When
an
user
request
episode
content
Then
she
is
able
to
see
it
22. What is a Model?
• How
do
you
represent
your
Model?
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 22
AUTOMATED
TESTS?
23. What is a Model?
• How
do
you
represent
your
Model?
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 23
CODE?
24. What is a Model?
• The
model
is…
• Everything
else
is…
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 24
THE
MENTAL
REPRESENTATION
JUST
COMMUNICATION
TOOL
25. Elaborate the Model
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 25
A
COLLABORATIVE
EXERCISE
26. Elaborate the Model
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 26
BASED
ON
A
COMMON
LANGUAGE
27. Elaborate the Model
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 27
Ingest
engineer
manages
brands
As
an
ingest
engineer
I
want
to
ingest
brands,
series
and
episodes
So
that
users
could
browse
them
EXPRESSED
AT
ALL
LEVELS
28. Elaborate the Model
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 28
EVOLUTIONARY
PROCESS
29. Elaborate the Model
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 29
EXPERIMENTING
IS
ESSENTIAL
30. Elaborate the Model
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 30
SO
DO
AUTOMATED
TESTING
Test
31. Ubiquitous Language
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 31
Technical
aspects
of
design
Technical
terms
Technical
design
paPerns
Business
terms
developers
don’t
understand
Business
terms
everyone
uses
that
don’t
appear
in
design
Domain
model
terms
Names
of
bounded
contexts
Terminology
of
large-‐scale
structure
DDD
paPern
names
UBIQUITOUS
LANGUAGE
Candidates
to
fold
into
model
32. Ubiquitous Language
Ubiquitous Language
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 32
Application
Code
Test
Code
Specs and
documentation
Whiteboard
discussions
Domain
Expert
Analyst Developer
Developer
34. Domain Modelling
• Typical
system
today
– Consist
of
a
few
subsystems,
responsible
for
mul;ple
func;ons
– Soaware/Domain
concerns
are
not
clearly
separated
• Which
func;ons
make
business
successful?
– Think
about
each
of
them
separately
– Do
NOT
create
one
model
of
the
whole
domain
– Otherwise
everything
will
be
connected
to
and
depend
on
everything
else
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 34
35. Domain Modelling – Basic Terms
• Domain
– Subject
area
where
the
soaware
will
be
applied
– Example:
VOD
Domain
• Subdomain
– Logically
separated
part
of
the
Domain
– Example:
Inges;on,
Streaming,
Geo
Loca;on
• Domain
Model
– Soaware
model
for
solu;on
of
a
domain
problem
• Bounded
Context
– Explicit
boundary
where
Domain
Model
lives
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 35
Source:
[Vernon,
DDD]
36. DomainSubdomain A
Subdomain B
Subdomain C
ProblemSpaceSolutionSpace
Bounded
Context A
Model
A
Bounded
Context B
Model
B
Bounded
Context C
Model
B
Problem-Solution Perspective
• Domains
have
problems
space
and
solu;on
space
• Problem
Space
– Strategic
business
challenge
to
be
solved
– Separate
it
into
Subdomains
• Solu;on
Space
– Implementa;on
of
the
soaware
to
solve
the
business
problem
– Bounded
Context
is
a
specific
solu;on
– The
model
lives
in
the
boundaries
of
Bounded
Context
• When
you
have
good
understanding
of
the
problem
space,
turn
it
into
solu;on
space
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 36
37. Source:
[Vernon,
DDD]
Subdomains
• Core
Domain
– part
of
the
business
that
is
of
primary
importance
– Example:
Asset
Metadata
Delivery
• Suppor;ng
Domain
– models
some
aspect
of
the
business
that
is
essen;al,
yet
not
Core
– Example:
Asset
Streaming
Info
• Generic
Domain
– captures
nothing
special
to
the
business,
yet
is
required
– Example:
GeoLoca;on
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 37
SO
DO
AUTOMATED
TESTING
38. Bounded Contexts
• Models
are
developed
in
Bounded
Contexts
• Linguis;c
boundary
in
which
the
model
exists
– Mark
off
where
the
meaning
of
every
term
used
by
the
domain
model
is
well
understood
– Example:
User
(Auth
Context:
Role)
and
User
(VOD
Context:
Content
Customer)
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 38
User
- role: Admin
- subscription: Series
Auth Context VOD Context
39. Bounded Contexts
• APempt
to
align
subdomains
one-‐to-‐one
with
Bounded
Contexts
• Could
influence
how
teams
are
organized
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 39
OrganizationLevelContextLevel
Context A
Context B
40. Context Mapping
• Mapping
the
contact
points
and
transla;ons
between
Bounded
Contexts
• Context
Mapping
PaPerns
– Shared
Kernel
• Shared
Subset
of
Domain
• Example:
Money
– Customer/Supplier
• Upstream
Project
–
Supplier
Team
• Downstream
Project
–
Consumer
Team
• Acceptance
test
at
Upstream
context
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 40
Context A Context B
Context A Context B
Uses agreed
interfaces
UD
41. Context B
Context Mapping
• Context
Mapping
PaPerns
– Conformist
– An;-‐Corrup;on
Layer
(ACL)
• Isola;ng
Layer
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 41
Context A
Context A Context B
Conform to existing
interfaces
UD
Adaptor1
Service1
Service2
Facade
Adaptor1
Translator2
Translator1
ACL
UD
42. Context Mapping
• Context
Mapping
PaPerns
– Separate
Ways
– Open
Host
Service
(OHS)
• a.k.a.
“Remote
Façade”
• Example:
REST
interface
– Published
Language
(PL)
• Example:
XML,
JSON
– Big
Ball
of
Mud
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 42
Context A Context B
43. Context Mapping
• So,
how
does
it
work?
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 43
Generic Domain
Context
Subdomain Context
Core Domain Context
U
D
OHS / PL
ACL
U
D
OHS / PL
ACL
U
D
OHS / PL
ACL
44. Context Mapping
• So,
how
does
it
work?
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 44
ContextA
Context B
Adapter
Application Service
Resource (REST)
/ OHS
HTTP Client (Façade)
Translator
ACL
45. Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Tactical DDD (DDD-Lite)
46. Source:
[Evans,
DDD]
Layered Architecture
The
DDD-‐Lite
is
applied
in
Domain
Layer
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 46
47. Entity
• A.k.a.
“Reference
Object”
• Has
Iden;ty
and
State
• May
have
mul;ple
representa;ons
– Example:
book
through
a
publishing
process
• Not
defined
primarily
by
their
aPributes
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 47
SO
DO
AUTOMATED
TESTING
48. Value Object
• Have
no
iden;ty
• Defined
by
its
aPributes
• Used
to
describe
the
state
of
En;ty
– as
its
aPribute
• Immutable
– Replacement
rather
than
modifica;on
• Could
be
implemented
as
Flyweight
[GoF]
• Example:
Colours,
Money,
Time
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 48
SO
DO
AUTOMATED
TESTING
49. Services
• Opera;on
which
does
not
conceptually
belongs
to
an
En;ty
or
Value
Object
• Fine-‐grained
domain
opera;on
over
domain
objects
– Usage:
Calcula;on,
transforma;on
etc.
• Domain
level
–
no
applica;on,
infrastructure
etc.
• Stateless
• Usually
Singletons
[GoF]
• Example:
– Triggers
En;ty
consistency
valida;on
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 49
SO
DO
AUTOMATED
TESTING
50. Domain Event
• Event
is
something
that
happened
in
the
domain
• Purpose:
to
makes
a
change
of
state
explicit
• Immutable
(it
happened
in
the
past)
• Data
holding
structure
(POJO)
• Class
naming
–
command
happened
in
the
past
– Example:
BrandRenamed
• Publish-‐Subscribe
(a.k.a.
Observer
[GoF])
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 50
51. Module
• A.k.a.
packages
• Divide
code
by
concepts
(not
by
technical
criteria)
• There
is
limit
to
how
many
things
a
person
can
think
about
at
once
(low
coupling)
• Choose
Modules
that
tell
the
story
of
the
system
• Example:
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 51
SO
DO
AUTOMATED
TESTING
[tld].[bounded-context-name].domain.[model | service|…].[conceptname]
com.piksel.vod.domain.model
com.piksel.auth.domain.model
com.piksel.vod.domain.model.assets
com.piksel.vod.domain.service
com.piksel.vod.resources.view
52. Aggregate
• A
cluster
of
associated
objects
(En;;es
and
Value
Objects
usually)
treated
as
a
unit
for
the
purpose
of
data
changes
• Root
(En;ty)
• Boundary
(what
is
inside
the
Aggregate)
• Enforces
invariants
(business
rules
which
should
be
always
consistent)
• Only
Aggregate’s
root
could
be
referenced
from
outside
objects
• Domain
Events
emission
– On
change
for
the
Aggregate
• Aggregate
Stores
– NoSQL
Key-‐Value/Document
Stores
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 52
53. Factory
• Constructors
-‐
“primi;ve
level
of
instance
crea;on…
for
the
programming
language”,
Evans
– use
only
for
very
simple
objects
-‐
straighlorward
construc;on!
• Crea;on
of
complex
En;;es/Value
Objects
• Implementa;on
-‐
various
crea;onal
(GoF)
paPerns
– Factory
Method
– Abstract
Factory
– Builder
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 53
54. Repository
• A
contract
between
applica;on
and
data
storage,
that
speaks
UL
• Repository
per
Aggregate
• Pretends
to
be
a
collec;on
of
Aggregate
Roots
• Isolates
Domain
Layer
from
persistence
details
• Uses
Factory
when
storing
new
object
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 54
Source:
[Evans,
DDD]
55. Repository
• Uses
Factory
when
recons;tutes
preexis;ng
object
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 55
Source:
[Evans,
DDD]
56. Specification
• Makes
implicit
business
rules
explicit
• It’s
a
predicate
• Allows
crea;on
of
Compound
Specifica;ons
(
using
NOT,
AND,
OR,
etc.)
• Used
for:
– Valida;on
– Selec;on
/
Queries
(by
Repository)
– Building
(Genera;on)
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 56
Source:
[Evans,
DDD]
58. Code / Example
• Example
project
– DDD-‐CQRS
Sample,
(v.02)
– HLA:
h'p://prezi.com/akrfq7jyau8w/ddd-‐cqrs-‐leaven-‐v20/
– Code
base:
h'ps://github.com/Bo'egaIT/ddd-‐leaven-‐v2
– User
Group:
h'ps://groups.google.com/forum/#!forum/ddd-‐cqrs-‐sample
• More
projects
on
official
CQRS
site
– hPp://cqrs.wordpress.com/examples/
Bulgarian Java User Group
Nikolay Vasilev, CC BY-SA 3.0
Domain Driven Design Page 58