Php melb cqrs-ddd-predaddy

Php Melb Talk

CQRS/DDD/predaddy

About Me

Douglas Reith – Technical Guy at Engagement Innovation

About Glow

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)

What is CQRS?

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

A Journey

http://didzsa22.deviantart.com/art/The-Mighty-Boosh-Wallpaper-396268100

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/

Why?

On the WRITE side -1)Simplify your domain models to be just about

business rules2)Data encapsulation (less accessor methods);

= Data Integrity + Maintainability

On the READ side -1)No (or very little) logic;

2)Aggregate and denormalise if you like;

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

A methodology and a modelling pattern

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

What is Event Sourcing?

(awkward silence)

predaddy

postdaddy

predaddy is a framework agnostic PHP CQRS/DDD library

There are others:https://github.com/PhpFriendsOfDdd/state-of-the-union

Why predaddy?

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

Where are we at?

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)

CQRS/DDD-lite:Is it YUK?

http://dooolittle.deviantart.com/art/Colourful-Dog-130580130

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 -● Hydrating scalar DTO's (commands) when

entering command handlers? e.g. Dates?

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!

More please:Search for DDD or CQRS – there are a few

articles about PHP and many more in .NET and Java.