Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Loosely
Coupled
Complexity


  Unleash
the
power
of
your
Domain

  Model
using
CQRS
&
Event
Sourcing
       Alberto.brando...
About
me
In
the
IT
field
since
ZX
Spectrum
Generally
in
large
scale
projects
(I
might
be
biased)
Freelance
consultant:
NotO...
@avanscoperta
www.avanscoperta.it
avanscoperta.wordpress.com
alberto.brandolini@avanscoperta.it




                      ...
These
3
guys

have
something

really
interesEng
to

share
What’s
wrong
with
that?



                            ApplicaEon
Services
            Remote
facade
     DTO




        ...
nothing
Thank
you
alberto.brandolini@avanscoperta.it
  hKp://ziobrando.blogspot.com
         twiKer:
ziobrando
...What

hump?




           ‐
Quale
gobba?
How
many
assumpEons

are
driving
our
choices?
let’s
try
again...



                            ApplicaEon
Services
            Remote
facade
     DTO




             ...
Anaemic Domain Model
Anaemic Domain Model

DTOs?
Anaemic Domain Model

DTOs?

Optimizing ORM queries
Anaemic Domain Model

DTOs?

Optimizing ORM queries

Development time
Anaemic Domain Model

DTOs?

Optimizing ORM queries

Development time

Testability
Anaemic Domain Model

DTOs?

Optimizing ORM queries

Development time

Testability

...
Do we really need...
Do we really need...

  a Domain Model?
Do we really need...

  a Domain Model?

  a Database?
Do we really need...

  a Domain Model?

  a Database?

  transactions?
Do we really need...

  a Domain Model?

  a Database?

  transactions?

  an Object Relational Mapper?
Do we really need...

  a Domain Model?

  a Database?

  transactions?

  an Object Relational Mapper?

  DTOs?
Anaemic
Domain
Model

       <<Ser vice>>               <<Entity>>

      OrderService
                                   ...
Not
every
present
is

 necessarily
nice
Advantages
of
Anaemic
Domain
Model
Advantages
of
Anaemic
Domain
Model

1)
Business
code
is
located
in
a
single
place:
Advantages
of
Anaemic
Domain
Model

1)
Business
code
is
located
in
a
single
place:
 Easier
to
read
for
young
developers
no...
Advantages
of
Anaemic
Domain
Model

1)
Business
code
is
located
in
a
single
place:
 Easier
to
read
for
young
developers
no...
Disadvantages
of
Anemic
Domain

            Model




Sad
as
a
hospital
meal
Disadvantages
of
Anemic
Domain

            Model


                 hard
to
maintain




Sad
as
a
hospital
meal
Disadvantages
of
Anemic
Domain

            Model


                 hard
to
maintain
                      hard
to
test

...
Disadvantages
of
Anemic
Domain

            Model


                  hard
to
maintain
                       hard
to
test...
Disadvantages
of
Anemic
Domain

            Model


                  hard
to
maintain
                       hard
to
test...
How
to
shoot
yourself
in
the
foot




                          avanscoper
                              ta
How
to
shoot
yourself
in
the
foot
  Design your application starting from the data model




                             ...
How
to
shoot
yourself
in
the
foot
  Design your application starting from the data model
  Create your domain model by rev...
How
to
shoot
yourself
in
the
foot
  Design your application starting from the data model
  Create your domain model by rev...
How
to
shoot
yourself
in
the
foot
  Design your application starting from the data model
  Create your domain model by rev...
How
to
shoot
yourself
in
the
foot
  Design your application starting from the data model
  Create your domain model by rev...
How
to
shoot
yourself
in
the
foot
  Design your application starting from the data model
  Create your domain model by rev...
How
to
shoot
yourself
in
the
foot
  Design your application starting from the data model
  Create your domain model by rev...
How
to
shoot
yourself
in
the
foot
  Design your application starting from the data model
  Create your domain model by rev...
I won’t reverse engineer my
data model to create a
domain model
I won’t reverse engineer my
data model to create a
domain model

I won’t reverse engineer my
data model to create a
domain...
I won’t reverse engineer my data
model to create a domain model

I won’t reverse engineer my data
model to create a domain...
I won’t reverse engineer my data
model to create a domain model

I won’t reverse engineer my data
model to create a domain...
I won’t reverse engineer my data model to
create a domain model

I won’t reverse engineer my data model to
create a domain...
I won’t reverse engineer my data model to create a
domain model

I won’t reverse engineer my data model to create a
domain...
How
should
we
implement
a
Domain
Model?
How
should
we
implement
a
Domain
Model?
How
should
we
implement
a
Domain
Model?
Behavior
should
be

placed
in
the


Domain
Model
How
should
we
implement
a
Domain
Model?
Behavior
should
be

placed
in
the


Domain
Model
Have
your
code

speak
the
Ubiquit...
How
should
we
implement
a
Domain
Model?
Behavior
should
be

placed
in
the


Domain
Model
Have
your
code

speak
the
Ubiquit...
How
should
we
implement
a
Domain
Model?
Behavior
should
be

placed
in
the


Domain
Model
Have
your
code

speak
the
Ubiquit...
Anemic
Domain
Model

      <<Ser vice>>               <<Entity>>

     OrderService
                                  Orde...
Rich
domain
model          <<Value Object>>
                          <<Entity>>
           ....
                         ...
s
           TDD
and
DDD
                       Frequent
rewriEng

       Focus
on
Unit
Tests
                            ...
Aggregate




            ©
Alberto
Brandolini
‐
2010
Aggregate


A
group
of
objects
that

naturally
belong
together
Unit
of
consistency
in
the

domain
model

updated
in
the
sa...
Aggregate
                              <<Entity>>         <<Value Object>>

                                         Orde...
MulEple
aggregates
                               Money
                    currency
                    amount

         ...
Isn’t
duplicaEon
bad?
‐   If
you
think
“data”
then,
...there’s
duplica6on

‐   If
you
think
“behaviour”
then
some
objects
...
It
turns
out
to
be
simple




                            ©
Alberto
Brandolini
‐
2010
Why
does
it
have
to
be
hard?




                          ©
Alberto
Brandolini
‐
2010
Hmm...
Once
coupling

between

aggregates
is

dramaEcally

reduced,
I
can

potenEally
choose

a
different

persistence

str...
From
the
same
old
stuff



                            ApplicaEon
Services
            Remote
facade
     DTO




         ...
TradiEonal
DDD
view



                             ApplicaEon
Services
             Remote
facade
      DTO




         ...
TradiEonal
DDD
view
           bou
             c o n n de d
                  te x
                       ts




        ...
TradiEonal
DDD
view



                             ApplicaEon
Services
             Remote
facade
      DTO




         ...
TradiEonal
DDD
view
            ag g
                 r   bou           ega
                               n d a te
      ...
TradiEonal
DDD
view



                             ApplicaEon
Services
             Remote
facade
      DTO




         ...
TradiEonal
DDD
view
     t hi
            na
                pp l


                                          ApplicaEon
S...
TradiEonal
DDD
view



                             ApplicaEon
Services
             Remote
facade
      DTO




         ...
Sending
Domain
Objects
to
the
UI?




                            ©
Alberto
Brandolini
‐
2010
Sending
Domain
Objects
to
the
UI?

‐ Nobody
really
likes
DTOs...




                                ©
Alberto
Brandolini
...
Sending
Domain
Objects
to
the
UI?

‐ Nobody
really
likes
DTOs...
‐ Some
tools
allow
that!
(let’s
have
some
more

  hawaiia...
Sending
Domain
Objects
to
the
UI?

‐ Nobody
really
likes
DTOs...
‐ Some
tools
allow
that!
(let’s
have
some
more

  hawaiia...
Sending
Domain
Objects
to
the
UI?

‐ Nobody
really
likes
DTOs...
‐ Some
tools
allow
that!
(let’s
have
some
more

  hawaiia...
Sending
Domain
Objects
to
the
UI?

‐ Nobody
really
likes
DTOs...
‐ Some
tools
allow
that!
(let’s
have
some
more

  hawaiia...
Sending
Domain
Objects
to
the
UI?

‐ Nobody
really
likes
DTOs...
‐ Some
tools
allow
that!
(let’s
have
some
more

         ...
How
would
you
implement
this?
                         As a Sales Office
                         I want to ship order on p...
Events
and
aggregate
coordinaEon
 ‐ Operafons
spanning
mulfple

    aggregates
shouldn’t
be
in
the
same

    Unit
of
Work
...
Domain
Event


‐ in
the
Ubiquitous
Language,
they’re

 Completed
AcEons:
verbs
in
past
tense.




                        ...
Asynchronously
responding
to
events
                                                          <<Domain Event>>
           ...
SOA
Anyone?
...just
draw
it
differently

     and
think
about

   “service
granularity”
Command/Query

 Responsibility

  SegregaEon
Why
do
we
have
to

choose
a
trade‐off?
StarEng
small...

‐ Command/Query
SeparaEon
was
an
OOD

 principle
part
of
DDD
 ‐   accessors
shouldn’t
have
side
effects
 ...
Command



!
      Usually
targeted
to
single
enEEes
      Behaviour
maKers
      Flexibility
maKers




                 ...
Query



?
        Large
amount
of
data
        No
behavior
        Performance
maKers
        Availability
of
off‐the
shel...
!
?
         UI
              DTO



   DTO
Remote
facade
ApplicaEon
Services
                      from
this...




     ...
!
?
                     UI
               DTO
                          DTO
                                           .....
!
        A
separate
path
for

      commands
issued
to
the

          Domain
Model




?   A
separate
path
for
querying

...
?               Querying
‐   Have
a
look
to
Users,
what
are

    they
really
interested
in?
    ‐   It’s
not
searching,
it...
?               Staleness
‐ Is
it
really
so
bad?
‐ Does
it
really
maKers
if
the
data
is...

    ‐ 20
seconds
old?
    ‐ Or...
?            It’s
just
data


‐   There’s
no
behaviour
in
what
we
see.
‐ Do
we
really
need
objects
for
that?

            ...
?       Query‐Only
Architecture
‐   It’s
just
(stale)
data:
no
behaviour...
    ‐   =>
Why
don’t
we
go
straight
to
the
dat...
?        Even
stale
data
can


‐ ...
provide
useful
informafon
for

    preliminary
validaEon
of
commands
    ‐ =>
less
fa...
!      ...less
failing
commands
    ‐ Since
most
of
our
commands
will
actually

      pass...
    ‐ ...
do
we
really
need
...
!             Capturing
user
intent
    ‐   Do
we
really
know
what
the
user
wants
to
do
with

        our
applicaEon?

   ...
!          Commands
!=
EnEEes


    ‐   There’s
not
so
much
in
common




                                        ©
Albert...
!                 Write‐only
model
    ‐   The
domain
model
is
not
used
to
collect
or
to
display

        data
        ‐  ...
!              PersisEng
the
model


    ‐   Do
we
really
need
to
persist
all
the
data?

    ‐   Do
we
really
need
to
pers...
!
?
                     UI
               DTO
                          Commands


Remote
facade             Remote
facad...
!
?
                      UI
                                                            voilà



               DTO
     ...
voilà

!

                                                                              ORM?
                             ...
!
?
                      UI
                                                            voilà



               DTO
     ...
do e
    voilà                                                       s it




!
                                          ...
!
?
                      UI
                                                            voilà



               DTO
     ...
!               A
nice
side
effect
    ‐   ...
fewer
collecfons

    ‐   =>
less
memory
footprint

    ‐   =>
less
Garbage
...
The
paper‐based
system



Many
business
pre‐date
computers
TransacEons
are
ocen
NOT
a

business
concern
Data
might
be
stal...
Event
Sourcing
!       So
what
is
our
DM
doing?

    ‐   basically
answering
to
self
contained
external

        messages...
        ‐   ...
!   Single
source
of
truth?




                        ©
Alberto
Brandolini
‐
2010
!        Single
source
of
truth?


    ‐   Once
it
used
be
paper...





                                    ©
Alberto
Bra...
!      Single
source
of
truth?


    ‐Once
it
used
be
paper...

    ‐ now
the
best
candidate
is
Events



                ...
!
?
                     UI
                                                          voilà

                             ...
!       Do
we
need
state
in
EnEEes?

    ‐   We
have
all
the
needed
informafon
in
the
Event

        Queue
        ‐   SIN...
!      Aggregates
and
events
                                           OrderCreated
                                     ...
!                 What
if
we...
    ‐ derive
the
Aggregate
state
from
the
sequence
of

      events
that
occurred
in
the
s...
!



    ©
Alberto
Brandolini
‐
2010
The
land
of
opportunity
Loosely
coupled

aggregates
allow
            be>er

simpler
                     scalability
deve...
Start
small
you
might
not
need
all
of
it
       each
step
is
an

        improvement
 Even
in
Eny
architectures
      ...c...
References

   h>p://groups.google.com/group/dddcqrs

h>p://cqrs.wordpress.com/

h>p://www.infoq.com/interviews/Architectu...
Thank
you
alberto.brandolini@avanscoperta.it
  hKp://ziobrando.blogspot.com
         twiKer:
ziobrando
Loosely Coupled Complexity - Unleash the power of your Domain Model with Command Query Responsibility Segregation and Even...
Loosely Coupled Complexity - Unleash the power of your Domain Model with Command Query Responsibility Segregation and Even...
Loosely Coupled Complexity - Unleash the power of your Domain Model with Command Query Responsibility Segregation and Even...
Loosely Coupled Complexity - Unleash the power of your Domain Model with Command Query Responsibility Segregation and Even...
Loosely Coupled Complexity - Unleash the power of your Domain Model with Command Query Responsibility Segregation and Even...
Loosely Coupled Complexity - Unleash the power of your Domain Model with Command Query Responsibility Segregation and Even...
Loosely Coupled Complexity - Unleash the power of your Domain Model with Command Query Responsibility Segregation and Even...
Upcoming SlideShare
Loading in …5
×

Loosely Coupled Complexity - Unleash the power of your Domain Model with Command Query Responsibility Segregation and Event Sourcing

22,241 views

Published on

Commented slides for the NHibernate day 2010 Presentaion

Published in: Technology, Business

Loosely Coupled Complexity - Unleash the power of your Domain Model with Command Query Responsibility Segregation and Event Sourcing

  1. Loosely
Coupled
Complexity Unleash
the
power
of
your
Domain
 Model
using
CQRS
&
Event
Sourcing Alberto.brandolini@avanscopertas.it
  2. About
me In
the
IT
field
since
ZX
Spectrum Generally
in
large
scale
projects
(I
might
be
biased) Freelance
consultant:
NotOnlyCode Trainer
(Freelance
&
Skills
MaKer
+
Zenika) Technical
Writer Blogger:
h>p://ziobrando.blogspot.com TwiKer:
ziobrando
 My
e‐mail:
 alberto.brandolini@gmail.com
  3. @avanscoperta www.avanscoperta.it avanscoperta.wordpress.com alberto.brandolini@avanscoperta.it ©
Alberto
Brandolini
2009
  4. These
3
guys
 have
something
 really interesEng
to
 share
  5. What’s
wrong
with
that? ApplicaEon
Services Remote
facade DTO ORM UI DTO ©
Alberto
Brandolini
‐
2010
  6. nothing
  7. Thank
you alberto.brandolini@avanscoperta.it hKp://ziobrando.blogspot.com twiKer:
ziobrando
  8. ...What
 hump? ‐
Quale
gobba?
  9. How
many
assumpEons
 are
driving
our
choices?
  10. let’s
try
again... ApplicaEon
Services Remote
facade DTO ORM UI DTO ©
Alberto
Brandolini
‐
2010
  11. Anaemic Domain Model
  12. Anaemic Domain Model DTOs?
  13. Anaemic Domain Model DTOs? Optimizing ORM queries
  14. Anaemic Domain Model DTOs? Optimizing ORM queries Development time
  15. Anaemic Domain Model DTOs? Optimizing ORM queries Development time Testability
  16. Anaemic Domain Model DTOs? Optimizing ORM queries Development time Testability ...
  17. Do we really need...
  18. Do we really need... a Domain Model?
  19. Do we really need... a Domain Model? a Database?
  20. Do we really need... a Domain Model? a Database? transactions?
  21. Do we really need... a Domain Model? a Database? transactions? an Object Relational Mapper?
  22. Do we really need... a Domain Model? a Database? transactions? an Object Relational Mapper? DTOs?
  23. Anaemic
Domain
Model <<Ser vice>> <<Entity>> OrderService Order registerOrder(...) date closeOrder(...) customer checkOrder(...) amount updateAvailability(...) ... getDate() setDate(...) getCustomer() setCustomer(...) getAmount() setAmount() ...
  24. Not
every
present
is
 necessarily
nice
  25. Advantages
of
Anaemic
Domain
Model
  26. Advantages
of
Anaemic
Domain
Model 1)
Business
code
is
located
in
a
single
place:
  27. Advantages
of
Anaemic
Domain
Model 1)
Business
code
is
located
in
a
single
place: Easier
to
read
for
young
developers
not
familiar
with
 OOP
  28. Advantages
of
Anaemic
Domain
Model 1)
Business
code
is
located
in
a
single
place: Easier
to
read
for
young
developers
not
familiar
with
 OOP Sorry,
can’t
find
number
2
:‐(
  29. Disadvantages
of
Anemic
Domain
 Model Sad
as
a
hospital
meal
  30. Disadvantages
of
Anemic
Domain
 Model hard
to
maintain Sad
as
a
hospital
meal
  31. Disadvantages
of
Anemic
Domain
 Model hard
to
maintain hard
to
test Sad
as
a
hospital
meal
  32. Disadvantages
of
Anemic
Domain
 Model hard
to
maintain hard
to
test fosters
duplicaEon Sad
as
a
hospital
meal
  33. Disadvantages
of
Anemic
Domain
 Model hard
to
maintain hard
to
test fosters
duplicaEon Sad
as
a
hospital
meal
  34. How
to
shoot
yourself
in
the
foot avanscoper ta
  35. How
to
shoot
yourself
in
the
foot Design your application starting from the data model avanscoper ta
  36. How
to
shoot
yourself
in
the
foot Design your application starting from the data model Create your domain model by reverse engineering avanscoper ta
  37. How
to
shoot
yourself
in
the
foot Design your application starting from the data model Create your domain model by reverse engineering Pretend that you’re doing TDD and start testing your domain classes avanscoper ta
  38. How
to
shoot
yourself
in
the
foot Design your application starting from the data model Create your domain model by reverse engineering Pretend that you’re doing TDD and start testing your domain classes Particularly getters and setters avanscoper ta
  39. How
to
shoot
yourself
in
the
foot Design your application starting from the data model Create your domain model by reverse engineering Pretend that you’re doing TDD and start testing your domain classes Particularly getters and setters Now start testing the logic with Integration Tests and get stuck by test data related issues avanscoper ta
  40. How
to
shoot
yourself
in
the
foot Design your application starting from the data model Create your domain model by reverse engineering Pretend that you’re doing TDD and start testing your domain classes Particularly getters and setters Now start testing the logic with Integration Tests and get stuck by test data related issues Declare that TDD provides no benefit and only slows you down avanscoper ta
  41. How
to
shoot
yourself
in
the
foot Design your application starting from the data model Create your domain model by reverse engineering Pretend that you’re doing TDD and start testing your domain classes Particularly getters and setters Now start testing the logic with Integration Tests and get stuck by test data related issues Declare that TDD provides no benefit and only slows you down Comment tests in your Build-Integration process avanscoper ta
  42. How
to
shoot
yourself
in
the
foot Design your application starting from the data model Create your domain model by reverse engineering Pretend that you’re doing TDD and start testing your domain classes Particularly getters and setters Now start testing the logic with Integration Tests and get stuck by test data related issues Declare that TDD provides no benefit and only slows you down Comment tests in your Build-Integration process Keep on whining avanscoper ta
  43. I won’t reverse engineer my data model to create a domain model
  44. I won’t reverse engineer my data model to create a domain model I won’t reverse engineer my data model to create a domain model
  45. I won’t reverse engineer my data model to create a domain model I won’t reverse engineer my data model to create a domain model I won’t reverse engineer my data model to create a domain model
  46. I won’t reverse engineer my data model to create a domain model I won’t reverse engineer my data model to create a domain model I won’t reverse engineer my data model to create a domain model I won’t reverse engineer my data model to create a domain model
  47. I won’t reverse engineer my data model to create a domain model I won’t reverse engineer my data model to create a domain model I won’t reverse engineer my data model to create a domain model I won’t reverse engineer my data model to create a domain model I won’t reverse engineer my data model to create a domain model
  48. I won’t reverse engineer my data model to create a domain model I won’t reverse engineer my data model to create a domain model I won’t reverse engineer my data model to create a domain model I won’t reverse engineer my data model to create a domain model I won’t reverse engineer my data model to create a domain model I won’t reverse engineer my data model to create a domain model
  49. How
should
we
implement
a
Domain
Model?
  50. How
should
we
implement
a
Domain
Model?
  51. How
should
we
implement
a
Domain
Model? Behavior
should
be
 placed
in
the

 Domain
Model
  52. How
should
we
implement
a
Domain
Model? Behavior
should
be
 placed
in
the

 Domain
Model Have
your
code
 speak
the
Ubiquitous
 Language
  53. How
should
we
implement
a
Domain
Model? Behavior
should
be
 placed
in
the

 Domain
Model Have
your
code
 speak
the
Ubiquitous
 Language Use
Aggregates
as
unit
 of
consistency
across
 your
domain
model
  54. How
should
we
implement
a
Domain
Model? Behavior
should
be
 placed
in
the

 Domain
Model Have
your
code
 speak
the
Ubiquitous
 Language Use
Aggregates
as
unit
 of
consistency
across
 your
domain
model Protect
your
model
 with
clearly
defined
 Bounded
Contexts
  55. Anemic
Domain
Model <<Ser vice>> <<Entity>> OrderService Order registerOrder(...) date closeOrder(...) customer checkOrder(...) amount updateAvailability(...) ... getDate() setDate(...) getCustomer() setCustomer(...) getAmount() setAmount() ...
  56. Rich
domain
model <<Value Object>> <<Entity>> .... Order LineItem registerOrder(...) date goods closeOrder(...) customer quantity checkOrder(...) amount notes updateAvailability(...) ... calculate amount() update() ... close() ship() ... <<Value Object>> <<Value Object>> Money Customer currency name amount surname address plus(Money other) minus(Money other) annota()... ...
  57. s TDD
and
DDD Frequent
rewriEng Focus
on
Unit
Tests Exploratory
coding Frequent
Short
Cycles Tiny
Domain
Objects Quick
Feedback Self
explanatory
code Freedom
to
change ©
Alberto
Brandolini
‐
2010
  58. Aggregate ©
Alberto
Brandolini
‐
2010
  59. Aggregate A
group
of
objects
that
 naturally
belong
together Unit
of
consistency
in
the
 domain
model updated
in
the
same
 transacEon deleted
together transferred
together ©
Alberto
Brandolini
‐
2010
  60. Aggregate <<Entity>> <<Value Object>> Order LineItem date goods A
group
of
objects
that
 customer amount quantity notes naturally
belong
together ... subtotal() update() ... close() Unit
of
consistency
in
the
 ship() ... domain
model <<Value Object>> <<Value Object>> Money Customer currency updated
in
the
same
 name amount surname address plus(Money other) transacEon minus(Money other) ... deleted
together transferred
together ©
Alberto
Brandolini
‐
2010
  61. MulEple
aggregates Money currency amount plus(Money other) minus(Money other) ... <<Entity>> <<Root>> <<Value Object>> <<Entity>> <<Root>> Order LineItem Customer date goods name customer quantity surname amount notes address ... subtotal() ... update() ... updateDiscount() close() ... ship() ... shipping address <<Value Object>> CustomerData billing address name surname <<Value Object>> Address <<Value Object>> street city country zipcode ©
Alberto
Brandolini
‐
2010
  62. Isn’t
duplicaEon
bad? ‐ If
you
think
“data”
then,
...there’s
duplica6on ‐ If
you
think
“behaviour”
then
some
objects
 definitely
are
not
the
same ‐ enforcing
aggregates
boundaries
makes
your
system ‐ strictly
consistent
within
the
aggregate
boundaries ‐ eventually
consistent
outside
the
aggregate
boundaries

 ©
Alberto
Brandolini
‐
2010
  63. It
turns
out
to
be
simple ©
Alberto
Brandolini
‐
2010
  64. Why
does
it
have
to
be
hard? ©
Alberto
Brandolini
‐
2010
  65. Hmm... Once
coupling
 between
 aggregates
is
 dramaEcally
 reduced,
I
can
 potenEally
choose
 a
different
 persistence
 strategy
for
each
 aggregate... ©
Alberto
Brandolini
‐
2010
  66. From
the
same
old
stuff ApplicaEon
Services Remote
facade DTO ORM UI DTO ©
Alberto
Brandolini
‐
2010
  67. TradiEonal
DDD
view ApplicaEon
Services Remote
facade DTO ORM UI DTO ©
Alberto
Brandolini
‐
2010
  68. TradiEonal
DDD
view bou c o n n de d te x ts ApplicaEon
Services Remote
facade DTO ORM UI DTO ©
Alberto
Brandolini
‐
2010
  69. TradiEonal
DDD
view ApplicaEon
Services Remote
facade DTO ORM UI DTO ©
Alberto
Brandolini
‐
2010
  70. TradiEonal
DDD
view ag g r bou ega n d a te r ie s ApplicaEon
Services Remote
facade DTO ORM UI DTO ©
Alberto
Brandolini
‐
2010
  71. TradiEonal
DDD
view ApplicaEon
Services Remote
facade DTO ORM UI DTO ©
Alberto
Brandolini
‐
2010
  72. TradiEonal
DDD
view t hi na pp l ApplicaEon
Services Remote
facade l ay ic at io DTOe r n ORM UI DTO ©
Alberto
Brandolini
‐
2010
  73. TradiEonal
DDD
view ApplicaEon
Services Remote
facade DTO ORM UI DTO ©
Alberto
Brandolini
‐
2010
  74. Sending
Domain
Objects
to
the
UI? ©
Alberto
Brandolini
‐
2010
  75. Sending
Domain
Objects
to
the
UI? ‐ Nobody
really
likes
DTOs... ©
Alberto
Brandolini
‐
2010
  76. Sending
Domain
Objects
to
the
UI? ‐ Nobody
really
likes
DTOs... ‐ Some
tools
allow
that!
(let’s
have
some
more
 hawaiian
shirts) ©
Alberto
Brandolini
‐
2010
  77. Sending
Domain
Objects
to
the
UI? ‐ Nobody
really
likes
DTOs... ‐ Some
tools
allow
that!
(let’s
have
some
more
 hawaiian
shirts) ‐ Validafon
creep ©
Alberto
Brandolini
‐
2010
  78. Sending
Domain
Objects
to
the
UI? ‐ Nobody
really
likes
DTOs... ‐ Some
tools
allow
that!
(let’s
have
some
more
 hawaiian
shirts) ‐ Validafon
creep ‐ Double
state
objects ©
Alberto
Brandolini
‐
2010
  79. Sending
Domain
Objects
to
the
UI? ‐ Nobody
really
likes
DTOs... ‐ Some
tools
allow
that!
(let’s
have
some
more
 hawaiian
shirts) ‐ Validafon
creep ‐ Double
state
objects ‐ Framework
temptafon
:‐( ©
Alberto
Brandolini
‐
2010
  80. Sending
Domain
Objects
to
the
UI? ‐ Nobody
really
likes
DTOs... ‐ Some
tools
allow
that!
(let’s
have
some
more
 ens hawaiian
shirts) ap p at h is ‐ Validafon
creep W h I U rom t he t f ‐ Double
state
objects in er en in ‐ Framework
temptafon
:‐( d iff oma e d th l! o de m ©
Alberto
Brandolini
‐
2010
  81. How
would
you
implement
this? As a Sales Office I want to ship order on purchase command In order to deliver purchased goods to the customer As a Marketing Office I want to assign discount points to customer on every purchase In order to enable more deals in the future ©
Alberto
Brandolini
‐
2010
  82. Events
and
aggregate
coordinaEon ‐ Operafons
spanning
mulfple
 aggregates
shouldn’t
be
in
the
same
 Unit
of
Work
 ‐ Communicafon
between
aggregates
 <<Domain Event>> is
inherently
asynchronous OrderPurchased ‐ Domain
Events
as
a
communicafon
 order where mechanism when amount ‐ from
the
outside payment method ‐ among
aggregates ... ... ©
Alberto
Brandolini
‐
2010
  83. Domain
Event ‐ in
the
Ubiquitous
Language,
they’re
 Completed
AcEons:
verbs
in
past
tense. ©
Alberto
Brandolini
‐
2010
  84. Asynchronously
responding
to
events <<Domain Event>> OrderPurchased order where when amount <<Entity>> <<Root>> payment method s u bs <<Entity>> <<Root>> s to ... cri b Order su b s c ri be e s to Customer date ... name customer surname amount address ... ... onPurchaseEvent(...) onPurchaseEvent(...) update() updateDiscount() close() ... ship() ... ‐ Don’t
forget:
Business
rules
everything!!! ©
Alberto
Brandolini
‐
2010
  85. SOA
Anyone? ...just
draw
it
differently
 and
think
about
 “service
granularity”
  86. Command/Query
 Responsibility
 SegregaEon
  87. Why
do
we
have
to
 choose
a
trade‐off?
  88. StarEng
small... ‐ Command/Query
SeparaEon
was
an
OOD
 principle
part
of
DDD ‐ accessors
shouldn’t
have
side
effects ‐ mutators
shouldn’t
return
a
value
 ‐ (with
the
excepfon
of
this
in
some
cases) ©
Alberto
Brandolini
‐
2010
  89. Command ! Usually
targeted
to
single
enEEes Behaviour
maKers Flexibility
maKers ©
Alberto
Brandolini
‐
2010
  90. Query ? Large
amount
of
data No
behavior Performance
maKers Availability
of
off‐the
shelves
components ©
Alberto
Brandolini
‐
2010
  91. ! ? UI DTO DTO Remote
facade ApplicaEon
Services from
this... ORM
  92. ! ? UI DTO DTO ...to
this Remote
facade Remote
facade ApplicaEon
Services Thin
Read
Layer ORM
  93. ! A
separate
path
for
 commands
issued
to
the
 Domain
Model ? A
separate
path
for
querying
 Data
  94. ? Querying ‐ Have
a
look
to
Users,
what
are
 they
really
interested
in? ‐ It’s
not
searching,
it’s
finding ‐ It’s
not
refreshing,
it’s
 looking
for
events ©
Alberto
Brandolini
‐
2010
  95. ? Staleness ‐ Is
it
really
so
bad? ‐ Does
it
really
maKers
if
the
data
is...
 ‐ 20
seconds
old? ‐ Or
10
minutes? ‐ ...
who
are
we
to
decide
this? ‐ ...
can
you
keep
a
print
in
sync? ©
Alberto
Brandolini
‐
2010
  96. ? It’s
just
data ‐ There’s
no
behaviour
in
what
we
see. ‐ Do
we
really
need
objects
for
that? ©
Alberto
Brandolini
‐
2010
  97. ? Query‐Only
Architecture ‐ It’s
just
(stale)
data:
no
behaviour... ‐ =>
Why
don’t
we
go
straight
to
the
database? ‐ No
coupling
between
UI
screens... ‐ =>
Do
we
really
need
referenEal
integrity? ‐ =>
Why
don’t
we
just
a
table‐per‐UI‐view
strategy,
 calculated
in
the
background? ‐ What
are
we
already
doing
with
the
search
model
 and
the
cache? ©
Alberto
Brandolini
‐
2010
  98. ? Even
stale
data
can ‐ ...
provide
useful
informafon
for
 preliminary
validaEon
of
commands ‐ =>
less
failing
commands ©
Alberto
Brandolini
‐
2010
  99. ! ...less
failing
commands ‐ Since
most
of
our
commands
will
actually
 pass... ‐ ...
do
we
really
need
to
answer
immediately
 on
the
same
channel? ‐ What
about:
“Thank
you
for
your
order,
your
 confirmaDon
e‐mail
will
arrive
shortly”? ©
Alberto
Brandolini
‐
2010
  100. ! Capturing
user
intent ‐ Do
we
really
know
what
the
user
wants
to
do
with
 our
applicaEon? ‐ Are
we
really
suppor6ng
our
users? ‐ Who’s
carrying
the
complexity
burden? ‐ ...
can’t
we
do
anything
smarter
than
just
showing
 raw
data? ‐ ...most
of
the
load
olen
turns
out
to
be
simply
useless ©
Alberto
Brandolini
‐
2010
  101. ! Commands
!=
EnEEes ‐ There’s
not
so
much
in
common ©
Alberto
Brandolini
‐
2010
  102. ! Write‐only
model ‐ The
domain
model
is
not
used
to
collect
or
to
display
 data ‐ Query
oriented
relafonships
between
enffes
no
longer
 needed. ‐ The
Domain
Model
is
always
in
a
consistent
state
(from
 Factory
to
Garbage
Collecfon) ‐ No
validaEon
on
the
Domain
Model
(commands
are
 validated
before) ‐ Tesfng
the
Domain
Model
turns
even
simpler ©
Alberto
Brandolini
‐
2010
  103. ! PersisEng
the
model ‐ Do
we
really
need
to
persist
all
the
data? ‐ Do
we
really
need
to
persist
it
in
Relafonal
Form? ‐ (remember,
we’re
not
running
queries...) ©
Alberto
Brandolini
‐
2010
  104. ! ? UI DTO Commands Remote
facade Remote
facade ApplicaEon
Services Thin
Read
Layer ORM
  105. ! ? UI voilà DTO Commands Remote
facade Remote
facade ApplicaEon
Services Thin
Read
Layer ORM? Eventually publish
subscribe
  106. voilà ! ORM? ApplicaEon
Services Remote
facade Commands Eventually UI Sp e publish
subscribe cia l i ze mo d d a Remote
facade DTO ? de l ta Thin
Read
Layer
  107. ! ? UI voilà DTO Commands Remote
facade Remote
facade ApplicaEon
Services Thin
Read
Layer ORM? Eventually publish
subscribe
  108. do e voilà s it ! t o b re e re a l l y ORM? ApplicaEon
Services Remote
facade l at ne e io n d a l? Commands Eventually UI Remote
facade publish
subscribe DTO ? Thin
Read
Layer
  109. ! ? UI voilà DTO Commands Remote
facade Remote
facade ApplicaEon
Services Thin
Read
Layer ORM? Eventually publish
subscribe
  110. ! A
nice
side
effect ‐ ...
fewer
collecfons ‐ =>
less
memory
footprint ‐ =>
less
Garbage
Collecfon ‐ on
some
systems,
the
DM
is
basically
always
 available ©
Alberto
Brandolini
‐
2010
  111. The
paper‐based
system Many
business
pre‐date
computers TransacEons
are
ocen
NOT
a
 business
concern Data
might
be
stale...
accept
it ASK
the
Business
  112. Event
Sourcing
  113. ! So
what
is
our
DM
doing? ‐ basically
answering
to
self
contained
external
 messages... ‐ events
from
the
UI
or
from
external
sources ©
Alberto
Brandolini
‐
2010
  114. ! Single
source
of
truth? ©
Alberto
Brandolini
‐
2010
  115. ! Single
source
of
truth? ‐ Once
it
used
be
paper...
 ©
Alberto
Brandolini
‐
2010
  116. ! Single
source
of
truth? ‐Once
it
used
be
paper...
 ‐ now
the
best
candidate
is
Events ©
Alberto
Brandolini
‐
2010
  117. ! ? UI voilà Events DTO Remote
facade Remote
facade ApplicaEon
Services Thin
Read
Layer ORM
? Events publish
subscribe
  118. ! Do
we
need
state
in
EnEEes? ‐ We
have
all
the
needed
informafon
in
the
Event
 Queue ‐ SINGLE
SOURCE
of
TRUTH ‐ What’s
an
Aggregate?
something
that
changes
its
 state
according
to
events ‐ ...according
to
the
current
understanding
of
the
system ©
Alberto
Brandolini
‐
2010
  119. ! Aggregates
and
events OrderCreated MAY 3 MAY ItemsAdded Order 5 Aggregates
 date customer PriceUpdated MAY 10 track
 amount ... Events
and
 onItemsAdded(...) MAY Order Purchased onPriceUpdated(...) onOrderPurchased(...) 12 derive
 ... MAY Order Shipped state
from
 15 that OrderDelivered MAY 25 JUN PaymentReceived 26 ©
Alberto
Brandolini
‐
2010
  120. ! What
if
we... ‐ derive
the
Aggregate
state
from
the
sequence
of
 events
that
occurred
in
the
system? ‐ =>
We
can
add
retroacEve
features... ‐ =>
We
can
say
YES
to
a
lot
of
interesfng/awkward
 request
for
the
business. ‐ =>
Reproducing
bugs? ©
Alberto
Brandolini
‐
2010
  121. ! ©
Alberto
Brandolini
‐
2010
  122. The
land
of
opportunity Loosely
coupled
 aggregates
allow
 be>er
 simpler
 scalability development Polyglot
 persistence Painless
 Rewindable
 SOA applicaEons
  123. Start
small you
might
not
need
all
of
it each
step
is
an
 improvement Even
in
Eny
architectures ...challenge
one
 assumpEon
at
a
Eme
  124. References
 h>p://groups.google.com/group/dddcqrs h>p://cqrs.wordpress.com/ h>p://www.infoq.com/interviews/Architecture‐Eric‐Evans‐Interviews‐Greg‐Young h>p://www.udidahan.com/2009/12/09/clarified‐cqrs/ h>p://www.infoq.com/presentaEons/Command‐Query‐Responsibility‐SegregaEon h>p://www.infoq.com/presentaEons/SOA‐Business‐Autonomous‐Components h>p://marEnfowler.com/eaaDev/EventSourcing.html h>p://skillsma>er.com/podcast/design‐architecture/architectural‐innovaEon‐evenEng‐ event‐sourcing ©
Alberto
Brandolini
‐
2010
  125. Thank
you alberto.brandolini@avanscoperta.it hKp://ziobrando.blogspot.com twiKer:
ziobrando

×