“Tribal knowledge” is information that should be written down but isn’t. If it were easy to write down, it probably already would be! Another common problem is with documentation quickly becoming obsolete. This month we’ll see a specific technique for helping a specific area of “tribal knowledge”. Our business processes run in phases according to […]

“Keep it simple” often does pay off. Here’s a method of creating observability, just for yourself, that’s intentionally simplistic and rapid to implement. by Edward Barnard

Like any software, PHP code can become rigid to the point that it’s difficult to change. When the change is needed by tomorrow, for example, it’s clear that a proper (multi-day) rewrite is not an option. With few automated tests in place, and none covering the area in question, adding tests to protect the modifications […]

When I drew out our PHP application on the whiteboard, it looked like a Big Ball of Mud. We changed the drawing slightly, and something interesting appeared. by Edward Barnard

Something was wrong in the sense that we missed our project deadlines repeatedly. What was wrong? This one took a while to figure out. We’ll look to Seymour Cray for part of the answer, and to James Grenning, one of the original signers of The Agile Manifesto, for the rest of that answer. by Edward […]

I realized that I need to experiment with various off-the-shelf products, such as Elasticsearch. Here is how and why I set up a Raspberry Pi as a safe testbed. We’ll repartition a USB hard drive to be suitable as the boot device while reaching past the boot device limitations. by Edward Barnard

The past two months focused on transactional-consistency boundaries. This month we’re extending the concept to RESTful API requests and responses. We’ll ensure that responses are internally consistent, whether success response, or error response. We’ll carefully draw and enforce the consistency boundary using the ancient wisdom of Yoda. by Edward Barnard

Planning for failure is difficult because it’s usually not practical to predict every possible thing that could go wrong. This month we’re creating a mechanism for capturing those “rare and random” failures. As we do so we’ll gain important insight regarding implementing invariants with a transactional boundary. by Edward Barnard

Domain-Driven Design’s Aggregate pattern is perhaps the most powerful of DDD’s tactical patterns. However, strangely enough, the pattern’s power doesn’t come from the Aggregate itself. The power comes from the Aggregate’s underlying concept–the transactional boundary. by Edward Barnard

This month presents a relatively quick code walkthrough even though this feature is more complex than the previous chapter. We’ll see the structure is similar to the Domain Event feature. We’ll focus on those points important to developing your instinct with Strategic Domain-Driven Design. by Edward Barnard