Transcript
Let people talk to businesses with one app:● Give some feedback, hold a conversation;● Get rewarded or donate to charity for you
structured feedback (surveys)
Separate your system into two parts:1) One that deals with client WRITES
(commands) – the Domain side2)And the other that deals with client READS –
the Query side
The Domain side doesn't know anything about the Query side.
The Domain is updated via Command objects (DTOs)
The Query sides knows about the Domain (can be limited)
The Query side is updated via Domain Events
Client: hello!
request
controllers
command bus
commandcommand
domain
command handler
AR
Entity
VO
Entity
VO
dosomething!
post()
event bus
domain eventdomain event
subscribe()
I didsomething!
Object Repository
save(AR)
load(AR)
Getting into the Domain
query
event listener
Read model
denormalise
event bus
domain eventdomain event
subscribe()
Object Repository
save(read model)
Getting into somewhere else
http://lonesomeaviary.wordpress.com/
On the WRITE side -1)Simplify your domain models to be just about
business rules2)Data encapsulation (less accessor methods);
= Data Integrity + Maintainability
Message Buses mean -1) Leaking the domain is hard - yay;
2)Extensions are easy;3)Avoiding transaction script is good;
4)Later we can do real messaging (MQ);
For Glow?
CQRS duplicates your data(there are ways to manage this, however)
Updates/Deletes are not fun when you duplicate your data.
Survey Responses + Conversations = Write and Read but we don't usually Update/Delete
Therefore – good alignment?
What is DDD?
http://commons.wikimedia.org/wiki/File:Orange_tabby_cat_sitting_on_fallen_leaves-Hisashi-01.jpg
Methodology:● Break down the whole domain into contextual
boundaries;● Be firm on language (ubiquitous language)
Modelling pattern -● Aggregate Roots rule
● Entities need to be identified● Value Objects are immutable
Then -● Events
● Repository● Service● Factory
predaddy is a framework agnostic PHP CQRS/DDD library
There are others:https://github.com/PhpFriendsOfDdd/state-of-the-union
1)I liked the code style/structure;2)Command bus message callbacks –
progressive enhancement3)Features ->
predaddy features -● Direct Command Bus
● Flexible Transaction Control● Testing fixtures
● Command validation
Check out my fork for a bundle of fun https://bitbucket.org/douglas_reith/riverline-predaddy-bundle
(update branch)
But sorry, predaddy 2.2 not 3
CQRS/DDD-lite:● On the Query side inject a domain repository;
● Everything is in one process;● Modelling is immature;
● Over reliance on doctrine lazy loading (context breaker)
DDD/CQRS-lite:Not ideal but you can progressively enhance -● Swap out the domain repo backing the read
model and swap in the query repo;● Start selecting messages
(COMMANDS/EVENTS) to be posted onto a Queue;
● Get better at DDD – do some refactoring, create separate repos, bundles, and refine your
language and contexts
Tricks -● Use domain event inheritence to listen to them
all;● You can post a command from an event listener;
● You can post a command from a command handler!
● Using NoSQL is a help
I've got questions -● REST versus CQRS/DDD. Do we need
impedance matching?➢ Nesting resources and ARs;
➢ Add 'command' string to Accept header;
I've got questions -● Name spaces, folder structure, repositories,
bundles● CQRS sends you down Domain/Query, but really
you can be more imaginative than that!
Warnings:● Performance – not given a good test, needs
work;● Developer velocity (files! files! files!) ;
● Reference sites/implementations;● Complicated doctrine configuration and niggly
bugs
More Warnings:● Events and Commands and Events and
Commands and... intent is less clear, sometimes best just let the domain do it's job directly
Don't forget the goodness:Light DTO's (events and commands), bounded contexts/domains, messaging buses = SOA in
memory!
Jump around, punch the air!
top related