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

»

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
»