Why use domain events?

Nota bene: this instalment in the Ports and Adapters with Command Handlers series is code-heavy, and isn't going to make much sense unless you've read the previous parts:

Okay, so we have a basic skeleton for an application and we can add new issues into the database, then fetch them from a Flask API. So far, though, we don't have any domain logic at all. All we have is a whole bunch of complicated crap where we could just have a tiny Django app. Let's work


Commands and Queries, Handlers and Views

In the first and second parts of this series I introduced the Command-Handler and Unit of Work and Repository patterns. I was intending to write about Message Buses, and some more stuff about domain modelling, but I need to quickly skim over this first.

If you've just started reading the Message Buses piece, and you're here to learn about Application-Controlled Identifiers, you'll find those at the end of post, after a bunch of stuff about ORMs, CQRS, and some casual trolling of junior programmers.

What is CQS ?

The Command Query Separation principle was first described by Bertrand Meyer in the


Repository and Unit of Work Pattern in Python

In the previous part of this series we built a toy system that could add a new Issue to an IssueLog, but had no real behaviour of its own, and would lose its data every time the application restarted. We're going to extend it a little by introducing some patterns for persistent data access, and talk a little more about the ideas underlying ports and adapters architectures. To recap, we're abiding by three principles:

  1. Clearly define the boundaries of our use cases.
  2. Depend on abstractions, not on concrete implementation.
  3. Identify glue code as distinct from domain logic and put it

Ports and Adapters with Command Handler pattern in Python

The term DDD comes from the book by Eric Evans: "Domain-Driven Design: Tackling Complexity in the Heart of Software". In his book he describes a set of practices that aim to help us build maintainable, rich, software systems that solve customer's problems. The book is 560 pages of dense insight, so you'll pardon me if my summary elides some details, but in brief he suggests:

  • Listen very carefully to your domain experts - the people whose job you're automating or assisting in software.
  • Learn the jargon that they use, and help them to come up with new jargon, so that