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.
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
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
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
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
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
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)
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.
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
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