Post on 16-Apr-2017
repeat myself. I will le
arn to repeat myself. I will le
arn to repeat myself. I will le
arn to
repeat myself. I will le
arn to repeat myself. I will le
arn to repeat myself. I will le
arn to
repeat myself. I will le
arn to repeat myself. I will le
arn to repeat myself. I will le
arn to
repeat myself. I will le
arn to repeat myself. I will le
arn to repeat myself. I will le
arn to
repeat myself. I will le
arn to repeat myself. I will le
arn to repeat myself. I will le
arn to
repeat myself. I will le
arn to repeat myself. I will le
arn to repeat myself. I will le
arn to
repeat myself. I will le
arn to repeat myself. I will le
arn to repeat myself. I will le
arn to
repeat myself. I will le
arn to repeat myself. I will le
arn to repeat myself. I will le
arn to
Douglas ReithOSDC 2015 Hobart
CQRS / DDD
About Me
I use random presentation transitions
< 4 years old = I lived with penguins
About Me
Tech guy at Engagement Innovation
Glowfeed.com
What's This About?
Software development and...
A way of thinking
Basic Truths - Language
We're wired for language
We play 'language games'
Basic Truths – Software Development
Change is constant
Especially at the start!
'Agile' Methodology
Codebase will GROW
Basic Truths – Software Development
BIG BALL OF MUD
What To Do?
It's not a new problem!
GNU/Linux: lots of binaries and authors
What do they do?
Interfaces/contracts
Isolated behaviour
High internal cohesion, low external coupling
Building an application...
it's still hard: time and 'resources'
HELP! - CQRS / DDD
Domain Driven Design (DDD)
'Domain-driven design (DDD) is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.'
http://dddcommunity.org/learning-ddd/what_is_ddd/
'Domain-driven design (DDD) is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.'
Domain Driven Design (DDD)
Ubiquitous language – agreed terms that are well-meaning and consistent within a bounded
context
Develop domain models with a reference to the bounded context
Domain Driven Design (DDD)
Domain models contain:
Value Objects (VOs)
Entities
Aggregate Roots (ARs)
- that emit Events
Command and Query Responsibility Segregation (CQRS)
Split your system -
Writing via Commands
Reading via Queries
CQRS / DDD – The Messaging Marriage
Commands distributed via a Bus
Domain Events distributed via a Bus
Commands and Domain Events are Messages
The Example
How does all this help?
The Example
Hi Doug, we need to build a cinema booking application. Our film-goers can book a seat through our application and before the film starts we'll send them an SMS or app notification telling them to get to their seats. Let's send them a notification if they change their password too, that'd be nice :)
The Example
package cinemaapp;
class User {
* register(email, password);
* authenticate(email, password);
* updatePassword(password);
* Notification[] notifications;
* addNotification(notification);
* Booking[] bookings;
* addBooking(booking);
}
More requirements please!
Hi Doug, we want the SMS to go if they haven't logged into the app recently.
Oh and our customers sometimes make group bookings, can you just add that please?
The Example
package cinemaapp;
class User {
* register(string email, string password);
* authenticate(string email, string password);
* Notification[] notifications;
* addNotification(Notification notification);
* Booking[] bookings;
* addNotification(Notification notification);
}
Hmmmm... add it h
ere?
Break It Down
Registration/Authentication
Notifications
Bookings
User
User
User
Now I am repeating myself
package users;
class User {
* register(email, password);
* authenticate(email, password);
* updatePassword(password);
}
package bookings;
class User {
* Group group;
* Booking[] bookings;
* addBooking(booking);
}
package notifications;
class User {
* Notification[] notifications;
* addNotification(notification);
}
Packages, packages, packages
'Package' can mean:● Business Domain● PHP Bundle/Library (definitely namespaced)● Bower update● Separate persistence store● Separate source control repository?● Indepedent – you can run unit tests without any other
packages
But, but, but
But how do we send the notification when they update their password?
How do we know when to send them a notification based on a booking?
Messages, buses and handlers
package users;
class User {
* updatePassword(password) {
raiseEvent(
new PasswordUpdated(userId)
)
}
}
package bookings;
class User {
* addBooking(booking) {
raiseEvent(
new BookingCreated(userId)
)
}
}
package notifications;
class PasswordChangeListener {
* handle(PasswordUpdated event);
}
The framework bus will find the right handler/listeners for you.
Language!
package users;
class AppUser {
* register(email, password);
* authenticate(email, password);
* updatePassword(password);
}
package bookings;
class FilmGoer {
* Group group;
* Booking[] bookings;
* addBooking(booking);
}
package notifications;
class Recipient {
* Notification[] notifications;
* addNotification(notification);
}
Consequences:● pushing language
up
Downsides
● Write more code● Lot's of packages/bundles/repositories/databases● Context switching● Developer onboarding – new names for things
(AR's, events etc)● Few reference sites?
Benefits
● 'Phil, write unit tests for cinema-app' vs 'write them for notifications'
● Dependencies are very clear● Straight forward progressions to microservices when you
want to● 'Deletability'● 'Swapability' – not the right language or persistence store
– don't worry!
Resources
PHP frameworks:● https://github.com/PhpFriendsOfDdd/state-of-the-union
● https://github.com/szjani/predaddy
A talk I gave previously including a full request/response journey:http://www.slideshare.net/DouglasReith/php-melb-cqrsdddpredaddy
Thanks
Organisers, Sponsors, and you
János Szurovecz, Greg Young, Eric Evans, Vaughn
Vernon
Extras?
The Journey