Why: CQRS is the new 'hotness' but beyond a desire to use the latest 'fad' what might actually lead you to adopt this approach over a conventional layered architecture. Looking back we will explore how some of the debates in the DDD community about how to implement Eric Evans ideas led people to the CQRS solution. We will look at some of the problems with aggregates and repositories that CQRS helps with and how the vision of seperating core from other domains is simplified. We will also look at simple steps to begin moving your layered application in the CQRS direction and give you a taste of what is to come. By the end of this session you should understand the problems that transitioning to CQRS will help you to resolve.

1. Just
flash
fashion
or
a
classic

2. Who
are
you?
 Software
Developer
for
18
years
 Worked
mainly
for
ISVs
 Reuters,
SunGard,
Misys
 Worked
for
a
couple
of
MIS
departments
 DTI,
Beazley
 Microsoft
MVP
for
C#
 Interested
in
OO
design
 Interested
in
Agile
methodologies
and
practices
 No
smart
guys
 Just
the
guys
in
this
room
Ian
Cooper
www.codebetter.com

3. Agenda
• here
did
it
all
go
wrong?
W
• he
problem
with
N-­‐Tier
T
• QRS
to
the
rescue
C
• emo
probably
here
D
• oing
further
G
Ian
Cooper
www.codebetter.com

4. Where
did
it
all
go
wrong
Why
the
N-­‐Tier
architecture
party
is
over.
Ian
Cooper
www.codebetter.com

5. The
Electronic
File
Ian
Cooper
www.codebetter.com

6. The
Data
Entry
Screen
Ian
Cooper
www.codebetter.com

7. Brave
New
World
 No
just
about
paper
input
any
more
 But
architecture
still
reflects
that
idea
 We
need
to
reflect
that
landscape
Ian
Cooper
www.codebetter.com

8. The
problem
of
CRUD
Why
are
we
failing?
Ian
Cooper
www.codebetter.com

9. RTFM
Ian
Cooper
www.codebetter.com

10. The
Old
Software
Lifecycle
 Software
design
began
with
CRUD
 Data
Flow
Diagrams
 Process
Diagrams
 IT
made
it
all
about
the
data
 But
it
was
really
all
about
the
goal
 What
was
the
data
used
for
Ian
Cooper
www.codebetter.com

11. But
what
about
MI
 Just
capturing
data
to
report
it
 But
what
happens
if
we
want
to
report
something
new?
 The
address
change
problem.
 Rarely
the
goal
 Reports
are
part
of
a
process
 What
do
we
do
with
that
report?
Ian
Cooper
www.codebetter.com

12. Insidious
CRUD
 This
might
be
good
for
‘catalogue
data’
 But
beware…
 If
I
set
state
through
CRUD
how
do
I
know
what
to
set?
 The
manual…
 Existing
Business
Process
 If
the
domain
model
is
the
rules
 Don’t
make
the
user
the
domain
model
Ian
Cooper
www.codebetter.com

13. Is
it
appropriate?
Ian
Cooper
www.codebetter.com

14. CQRS
to
the
rescue!
Of
course
there
is
no
silver
bullet…
Ian
Cooper
www.codebetter.com

15. Some
N-­‐Tier
problems
Ian
Cooper
www.codebetter.com

16. Breaking
out
commands
Ian
Cooper
www.codebetter.com

17. Diets
can
be
healthy
Ian
Cooper
www.codebetter.com

18. Beware
Vampires
Ian
Cooper
www.codebetter.com

19. Handling
a
Command
 Load
everything
we
need
via
infrastructure.
 Usually
we
only
have
one
aggregate
from
repository.

May
have
other
stuff
such
as
information
from
web
service
calls
 Exercise
one
method
on
the
aggregate
root
 This
method
is
here
to
keep
us
from
bleeding
business
logic
into
the
command
handler
 If
we
need
more
than
one
aggregate
involved
we
raise
an
event
for
other
aggregate
roots
to
handle
 Persist
and
clean
up
via
infrastructure
Ian
Cooper
www.codebetter.com

20. Query
Questions
Answered
Ian
Cooper
www.codebetter.com

21. Data
Structures
and
Objects
 Data
Structure
 Has
public
state
but
not
behavior
 Class
 Has
behavior,
encapsulates
state
Ian
Cooper
www.codebetter.com

22. Two-­‐Tier
is
Enough
Presentation
Infrastructure
DB
Ian
Cooper
www.codebetter.com

23. Show
Us
Some
Code
Then!
 We
wander
around
some
demo
code
 We
will
try
to
show
the
steps
to
CQRS
 Though
be
warned
it
may
get
scrappy
Ian
Cooper
www.codebetter.com

24. Going
Further
Command-­‐Query
separation
first
step
on
journey
of
a
thousand
miles
Ian
Cooper
www.codebetter.com

25. Event
Sourcing
Ian
Cooper
www.codebetter.com

26. Ian
Cooper
www.codebetter.com

27. Eventual
Consistency
Ian
Cooper
www.codebetter.com

28. No
one
will
do
that!
How
to
overcome
doubts
on
cost
Ian
Cooper
www.codebetter.com

29. Strategic
Design
 Strategic
Design
 Core
 Supporting
 Generic
Ian
Cooper
www.codebetter.com

30. CQRS
–
Command
and
Query
Responsibility
Segregation
• oby
Henderson
T
• holytshirt
@
• endersont@gmail.com
h
• ttp://holytshirt.blogspot.com
h

31. CQRS
C#
example
 http://github.com/MarkNijhof/Fohjin
 ttp://bit.ly/prognetcqrs
h
 Mark
Nijhof
 http://elegantcode.com/about/mark-­‐nijhof/

32. Queries
–
CQS
 Return
a
result
and
do
not
change
the
observable
state
of
the
system
(are
free
of
side
effects).
-­‐
“Bertrand
Meyer”
 Asking
a
question
should
not
change
the
answer.

33. Queries
–
CQRS
 Any
need
for
data
from
the
system
is
a
reporting
need;
this
includes
the
various
application
screens
which
the
user
uses
to
base
his
decisions
on.
–
Greg
Young
 Showing
user
information
involves
no
business
behaviour
and
is
all
about
opening
up
that
data.
–
Udi
Dahan

34. Before
CQRS
CompanyService
void
CreateCompany(Company)
Company
GetCompany(CompanyId)
List<Company>
GetCompaniesWithName(Name)
void
EditCompanyDetails(CompanyDetails)
void
Delete
Company(CompanyId)

35. Applying
CQRS
CompanyWriteService
void
CreateCompany(Company)
void
EditCompanyDetails(CompanyDetails)
void
DeleteCompany(CompanyId)
CompanyReadService
Company
GetCompany(CompanyId)
List<Company>
GetCompaniesWithName(Name)

36. Database
Data
Domain
Model
Read
Write
DTO
View
Model
View

37. Database
Data
Data
Domain
Model
Read
Write
Services
View
Model
View
Model
View
View

38. Sync
Database
Database
Data
Data
Domain
Model
Read
Write
Services
View
Model
View
Model
View
View

39. Sync
Database
Data
Read
View
Model
View

40. Store
View
Model
 Put
ViewModel
in
the
database
/
storage.
 A
table
for
each
view
or
as
much
as
the
view
as
possible.
 Very
fast
with
little
or
no
transformation.
 Database
can
become
a
cache.
 No
need
for
ORM.
 Cheap.
 Data
is
stale
anyway.

42. @NeilRobbins
neil@computer.org

43. Don
Box’s
4
Tenets
of
SOA
 Boundaries
are
explicit
 Services
are
autonomous
 Services
share
schema
and
contract,
not
class
 Service
compatibility
is
determined
based
on
policy

44. The
Open
Groups
Definition
of
a
Service
 Is
a
logical
representation
of
a
repeatable
business
activity
that
has
a
specified
outcome
(e.g.,
check
customer
credit,
provide
weather
data,
consolidate
drilling
reports)
 Is
self-­‐contained
 May
be
composed
of
other
services
 Is
a
“black
box”
to
consumers
of
the
service
From:
http://www.opengroup.org/soa/source-­‐book/soa/soa.htm

45. Some
Visions
of
SOA
“Implementing
SOA
the
right
way
The
figure
below
depicts
a
well-­‐designed
SOA.”
IMO
–
A
Vendors
wet-­‐dream
All
in
terms
of
infrastructure,
none
in
terms
of
business!
From:
http://www.javaworld.com/javaworld/jw-­‐11-­‐2006/jw-­‐1129-­‐soa.html?page=3

46. Some
Visions
of
SOA
From:
http://www.ibm.com/developerworks/webservices/library/ws-­‐WSBFoverviewpart1/index.html

47. Some
Visions
of
SOA
From:
http://www.infoq.com/articles/SOA-­‐enterprise-­‐data

48. A
Vision
of
SOA
Composite
UI

49. A
Vision
of
SOA
Shopping
Cart
Service
Command
Command
Ratings
Service
Command
Product
Command
Images
Service
Command
Command
Command
Buying
Choices
Service
Bought
Together
Offers
Service
Service

50. A
Vision
of
SOA
Composite
UI
(also
a
service)
Shopping
Bought
Product
Ratings
Offers
Cart
Together
Images
Service
Service
Service
Service
Service

51. Not
just
aligned
with
Business
Activity
 So
each
service
has
its
own
requirements
 Not
just
the
‘strictly’
functional
 So
what
might
we
consider

52. Yield
 AKA
Availability
 A
measure
of
the
probability
of
completing
a
request
 Typically
measured
in
9s
(eg
0.9999)
 A
very
common
measure
in
SLAs

53. Harvest