The July 2022 article “Structure by Use Case” introduced the Bounded Context pattern, which we’ll be using over and over as we structure our software by use case. This month we’ll continue exploring these concepts as we implement the global Domain Event store. by Edward Barnard

Last month “Structure by Use Case” introduced the Bounded Context pattern we’ll be using over and over as we structure our software by use case. This month we’re diving more deeply into the boundaries, the crossing points, and the software layers created by this pattern. by Edward Barnard

This month we’re introducing the Strategic Domain-Driven Design pattern that we’ll be repeating over and over as we build out our project. by Edward Barnard

Designing for failure is difficult because it’s usually not practical to predict every possible thing that could go wrong. Last month we got the preliminary “spadework” out of the way. This month we begin our first feature. This feature creates a mechanism for capturing those “random and rare” failures.

This month we begin the preliminary “spadework” to set up our project. We’ll be taking a hands-on “code first” approach to implementing Strategic Domain-Driven Design. by Edward Barnard

When the new requirement arrives, does this mean we cram it in the best place, making our software more difficult to work with, or might we have ways to make the result cleaner than before we started? We’ll take advantage of Martin Fowler’s concept of Preparatory Refactoring.

Last month, we created “role-based lookups” with “When You Know the Pattern.” Database-related code can be difficult to unit test, and once unit tests are written, they can be difficult and time-consuming to maintain. This month we’ll carefully look at this problem and possible solutions. We’ll walk through the test suite after extensive refactoring to […]

Software design patterns provide a “voice of experience” that can help solve the problem you’re trying to solve. However, it’s often not obvious how to implement any such design pattern within our modern PHP ecosystem. Here’s an example solution. We are implementing a memoizing Registry that’s outside my CakePHP framework code but uses CakePHP’s database […]

We begin our implementation of Domain-Driven Design with simple refactoring. We’ll take a close look at what complexity might be hidden within the expected implementation. That observation will guide us in refactoring toward Domain-Driven Design. by Edward Barnard