So far we’ve spent a lot of time and energy on a simple problem that we could
easily have solved with Django. You might be asking if the increased testability
and expressiveness are really worth all the effort.
In practice, though, we find that it’s not the obvious features that make a mess
of our codebases: it’s the goop around the edge. It’s reporting, and permissions,
and workflows that touch a zillion objects.
Our example will be a typical notification requirement: when we can’t allocate
an order because we’re out of stock, we should alert the buying team. They’ll
go and fix the problem by buying more stock, and all will be well.
For a first version, our product owner says we can just send the alert by email.
Let’s see how our architecture holds up when we need to plug in some of the
mundane stuff that makes up so much of our systems.
We’ll start by doing the simplest, most expeditious thing, and talk about
why it’s exactly this kind of decision that leads us to the Big Ball of Mud.
Then we’ll show how to use the Domain Events pattern to separate side effects from our
use cases, and how to use a simple Message Bus pattern for triggering behavior
based on those events. We’ll show a few options for creating
those events and how to pass them to the message bus, and finally we’ll show
how the Unit of Work pattern can be modified to connect the two together elegantly,
as previewed in Figure 8-1.
Figure 8-1. Events flowing through the system ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month, and much more.
