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
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
V anilla 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?
(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.
– 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.”
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.
– 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.”
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
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
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
– 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.”
“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
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.
Adv ant ages 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
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
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.
doggy
syossan27
pocke
sagawa23
ojun9
cer
horie1024
kumamotone
masatoshiitoh
77web
ymotongpoo
akatsuki174
thekraken
denniskardys
afnizarnur
kevinliebholz
marcduiker
holman
bkeepers
jennybc
robhawkes
frogandcode
brianwarren
tanoku