For our 10th anniversary, we have asked some or our speakers to reflect on how Domain-Driven Design, the community, or the conference itself has evolved over the past decade.

Chelsea Troy has spoken at DDD Europe on multiple occasions and has given workshops for DDD Academy. She writes code for projects like the Zooniverse Citizen Science Mobile App and the NASA Landsat Image Processing Pipeline, focusing on work that saves the planet, advances scientific research, or serves underserved communities. Chelsea also teaches Mobile Software Development at the University of Chicago's Master's Program in Computer Science and is the author of chelseatroy.com and the book Remote Work Sucks. When she's not coding or teaching, she organizes two conferences: PromptConf and ORD Camp, both in the Chicago area.

Decision-Making Armatures: The Legacy of Domain-Driven Design

by Chelsea Troy - 5 minute read

I live in Chicago, a city with such historically frigid winters that people call it “Chiberia.” The turn of the year isn’t exactly, ahem, running season. Nevertheless, in any week with a few days above about 20°F (that’s -7°C), I try to log a handful of miles. Each time I lace up my Brooks sneakers, I think about Rebecca Wirfs-Brock.

Rebecca taught me a couple of things during my first year at DDD Europe. First, she suggested that if I didn’t like my running shoes, I might try a pair of Brooks like she did (which worked for me). Second, she gave me new intuition for a thing I had used all my life: the heuristic.

To me, “heuristic” meant a simple observation I’d use to make a judgment call if I lacked the tools, the time, or the expertise to do something more rigorous. A heuristic for judging whether a cake has finished baking is to stab the flesh with a toothpick and see that the toothpick comes out clean. Is this foolproof? No: in fact, I think it frequently leads to dry, unappetizing cakes. But it’s better than nothing, and I guess I’d still prefer a dry cake over a raw one.

Software development hosts plenty of instances of “inaccurate metric, still better than nothing.” The rule of three for DRYing up code is a heuristic. “Consider breaking out a helper method if your original method exceeds 4-5 lines” is a heuristic.

However, in my humble opinion, we developers fumble the use of the heuristic in two ways:

1. We use heuristics as rules: “The rule of three says I have to DRY up this code now.” No it doesn’t. That “rule” is meant to roughly encompass a probability judgment. It’s a tool, not a law. The decision still belongs to you.
2. Unless there is already a popular heuristic for us to use, we don’t use heuristics at all. We instead pretend to apply a perfectionist approach to our craft with no backoff mechanism, no plan B. We claim to use outside-in test driven development all of the time, except in specific edge cases. What do we do in the edge cases? YOLO. Guessing. Intuition. “We are very smart, so our assumptions will probably work, right?” “…..right?”

I have worked in software for the better part of two decades. I have only seen the field trend toward more uncertainty, not less. We lack the tools, time, or expertise to make rigorous judgment calls at least as often as we ever have, that I have seen.

The year Rebecca taught me about Brooks sneakers and heuristics, I delivered a hands-on workshop at DDD Europe about evaluating risks in a software system. My workshop addressed a specific example of heuristic failure mode #2. We’ve got labor-intensive, perfectionist approaches to analyze risk (six sigma, etc). But in the absence of the tools, time, or expertise to use them, developers just…guess. And it turns out, in the aggregate, developers are not great at guessing. I wanted to introduce a risk mitigation decision framework that was accurate enough to be useful, but necessarily also, simple enough to be actually used. Here are materials from an instance that workshop, if you’re curious).

That year, and again in the workshops I gave the year after, people asked me how my material relates to Domain Driven Design. I got the question enough that I started anticipating it. I’d jam a slide into every presentation attempting to relate what I had to say to bounded contexts, or the tactical patterns, or something else I figured my audience had read in Eric Evans’ book.

But actually, I think the relationship is one of common ancestry. I think Domain Driven Design pioneered the practice of solving for the following equation:

Developers, devoid of a heuristic framework, have demonstrated that they will do either rigorous perfectionism or a complete guess. In software development, uncertainty frequently eliminates perfectionism as an option, but a complete guess produces the wrong answer a lot of the time. Can we give developers armatures for decision-making that they can use in lieu of perfection for preferable results over guessing?

DDD attempts to provide that armature specifically for making decisions about a software system’s domain. In so doing, it paves the way for other contributors to provide armatures for other sorts of development decisions. My workshop from 2023 attempts to provide that armature specifically for making decisions about a software system’s risk profile. And Rebecca Wirfs-Brock’s work attempts to provide armature on a meta level: it enables engineers to choose between multiple armatures, or even generate their own armatures when a perfect solution isn’t available.

I think future DDD conferences could explicitly bring people together to develop and discuss decision-making armatures. Where could we use new ones? Where could we improve existing ones? How could our armatures respond to evolutions of our teams, our employers, or our technology? Where do we still find ourselves dealing with slippery concepts in our roles, and where might we install handles to make those concepts easier to grasp?

I’m giving a pre-conference workshop at DDD Europe 2026 called AI-Augmented Software Engineering. So far, I’ve designed that workshop to answer those questions specifically for making decisions with AI code assistants. Where is the idea of an LLM code assistant slippery? What inaccuracies does that produce in the way people guess at how to use them? Where can I install some handles to make these concepts more wieldable for those with engineering background, but not LLM expertise? I’ll be thrilled to see which other armatures my colleagues bring to the conference this year, and I’m optimistic for conversations about Domain-Driven Design as an inspiration for decision-making armatures in each area of our evolving work.

Chelsea Troy will also speak at DDD Europe 2026 on June 10 - 11 - 12, 2026, in Antwerp, Belgium. Tickets are available below.