10. The Problem(s)
Huge growth led to a huge monolith
Finance, especially FinTech, is a rapidly changing market
New threats mean changes in compliance and security
14. Domain logic is changing constantly
Spotify “model” is improving agility but frameworks/
libraries diverging across squads
We have a zillion internal endpoints on our APIs
(Still Some) Problems
17. Vanilla Ice says…
We’re not going to refactor all these working APIs
just to use the same framework.
We do need a common way to handle all these
changing things though.
What lets us plug in new functionality really easily?
18. (Some) B etter Solutions
Command buses to tell our domain that we want to do
something.
Event buses to inform our domain that something has
been done.
Action-Domain-Responder pattern to control the
interaction between the framework and the command
bus.
25. – Wikipedia
“In object-oriented programming, the command
pattern is a behavioral design pattern in which an
object is used to encapsulate all information
needed to perform an action or trigger an event
at a later time.”
26. – Wikipedia
“This information includes the
method name, the object that owns
the method and values for the
method parameters.”
27. In other words…
A (very) simple Data Transfer Object (DTO)
Knows nothing about how it will be used
Only knows enough to complete the command
Operate as a Value Object in your Domain.
31. – The League of Extraordinary Packages
“The term is mostly used when we combine
the Command pattern with a service layer.”
32. – The League of Extraordinary Packages
“Its job is to take a Command object (which describes what
the user wants to do) and match it to a Handler (which
executes it). This can help structure your code neatly.”
37. Drupal started with “hooks” - simple named pub/sub
Zend Framework (0.x - 1.x) had the “Dispatch cycle”
SPL Observer/Subject for implementing Observer pattern
Symfony Event Dispatcher (et al)
Bounce (coming soon)
The Evolution of Event buses in PHP
42. Commands and Events are both simple DTOs
Beautifully dumb
Should be self-validating
Commands know (or infer) the one to one relationship
with a single handler
Comparing Commands and Events
43. Know nothing about the mechanism
Only know about their Commands/Events
Extremely easy to test
Command bus abstracts the Command-Handler relationship
Event bus manages the many-to-many Event/Listener
relationship
Command Handlers AND Event Listeners
45. – Alistair Cockburn
“Allow an application to equally be driven by users,
programs, automated test or batch scripts, and to be
developed and tested in isolation from its eventual
run-time devices and databases.”
52. “Take as long as you need to understand your
domain logic before building a working product. Your
product can change, your logic shouldn’t.”
– No CEO ever
56. Downsides
Code duplication is exponential with the number of
services involved.
HTTP Controllers and console are inherently knowing
more about your domain through endpoint names.
Infers you know your Domain upfront.
59. Advantages
The Controller’s single responsibility is turning a Request
into a Command
Command Bus easily mocked to test HTTP adapter.
Interactions between services within the Domain
abstracted away.
Can write the HTTP side of the app without knowing any
domain services
67. Action-Domain-Responder
First heard of it via the Slim framework
documentation
“Web-specific refinement of the MVC pattern”
More suited to the closure-based micro frameworks
https://github.com/pmjones/adr
89. Switch out the action/responder pair for any adapter
Responder can be as smart or dumb as you like
Multiple events can populate the Responder
CQRS and Command/Events fit well together
Self-validating DTOs allow you to “read your own
writes”
“Succeed or Throw” makes application logic simpler.