I’ve been playing Dungeons & Dragons a long time, a REALLY long time. My first D&D game was the not quite original 1st Edition Basic Rules boxed set (the 1981 revision that came with Keep on the Borderlands, not the original 1977 version). Over the years I’ve learned quite about about playing, running, and designing D&D adventures. Some of them have gone well. Some of them, not so well.

Turns out, learning how to design and run a D&D campaign can also teach you a lot about how to design and run a software development project. Good game design and good software architecture share a lot of the same core principles. Let’s look at why.

The Dungeon Master Is The Architect

The DM doesn’t play the game. They design the world. They decide what the story is, how it all fits together, and what pieces the players will have a part in. That’s a lot like a software architect. The architect doesn’t write a lot of the code. Instead, they define the boundaries, the rules, the events, and the interactions.

However, without the players (the development team), a lot of that world would never get put together. Just like the DM needs a cast of players to bring their world alive, an architect needs a team of software developers to bring their design to fruition. Yeah, you could play by yourself, but it’s nowhere near as fun.

The best DMs (and architects) make decisions that will let the players be the best versions of themselves, encouraging buy-in and a desire to bring the campaign (or software project) to its full potential. They don’t railroad the players (or micromanage the developers). They do provide proper guidance where needed. In the end, everyone feels a sense of accomplishment.

Character Classes Are Bounded Contexts

Each character class in D&D has a defined role and a clear area of responsibility. The fighter absorbs damage and controls the battlefield. The wizard blasts enemies from range and deciphers arcane lore. The rogue disarms traps and opens locked doors. The cleric keeps everyone alive long enough to do it again. These aren’t arbitrary divisions — they exist so every piece of the party has a clear purpose and doesn’t step on the others.

The same principle applies to your software architecture. In Domain-Driven Design and Clean Architecture, we call these bounded contexts. Each part of the application owns its domain, its rules, and its data. They interact through well-defined interfaces, not by reaching into each other’s business. When your architecture respects those boundaries, the whole system stays coherent and maintainable.

When it doesn’t? Well, that’s when your fighter starts casting fireball spells. (And unless they happen to believe they are Keraptis, that’s a problem.)

The Party Is Your Team, And It Needs Balance

Bounded contexts keep your architecture healthy. But the same thinking applies to the people building it.

A party of all wizards looks impressive until the first combat — they’ll shred anything at range but fall apart the moment an enemy gets close. A party of all fighters will bulldoze every monster they meet, then grind to a halt at the first locked door or magical puzzle. You need balance: people who cover different ground, complement each other’s strengths, and shore up each other’s weaknesses.

Your development team is no different. A team of all front-end developers will build a beautiful UI with no API behind it. A team of all architects will produce stunning diagrams and zero working software. You need developers across the stack, QA to keep quality honest, and someone to keep the project moving forward. Generalists are valuable, but specialists win the hard fights. The goal is a roster where no single gap can stall the whole party.

Encounters Are a Lot Like Load Testing

A good DM knows the capabilities and limits of the party, and they adjust the encounters accordingly. They don’t make them so easy the party gets bored, or so difficult that the party gets wiped out in the first round. They get to learn the limits of all the pieces involved. Likewise, in software design you need to learn the limits of the system before Vecna shows up to face the adventurers.

A DM does this by starting small and gradually increasing the difficulty to the point where they can handle encounters as they come. A good architect does this by stress testing, chaos engineering, and planning for appropriate capacity scaling and reaction.

The Rulebook Is Your Domain Model

Every D&D campaign runs on a shared set of rules. The Player’s Handbook defines what’s possible — what spells exist, how combat works, what your character can and can’t do. Everyone at the table agrees to play by those rules, and that shared understanding is what makes the game work.

Your domain model does the same thing for your software. It defines the language everyone speaks, the rules the system enforces, and the boundaries it will never cross. It’s the thing you point to when someone asks “wait, can we do that?” — and sometimes the answer is no.

Now, most tables have house rules. Small agreed-upon variations that fit their group better than the published standard. And that’s fine — sometimes the rules as written don’t fit your situation. But house rules have a cost. They’re undocumented assumptions that new players (or new developers) have to learn the hard way. Let them accumulate unchecked and you’ve quietly built a system nobody fully understands anymore. That’s intentional technical debt — chosen deliberately, but debt all the same.

Side Quests Are Technical Debt

Side quests aren’t always bad — sometimes the treasure at the end is worth the detour. The problem is when you don’t realize you’re on a side quest until you’re three sessions deep and the main storyline has gone cold. That’s the difference between house rules and side quests as technical debt: house rules are debt you chose with your eyes open; side quests are debt that snuck up on you.

In software, this looks like the “quick refactor” that turned into a two-week rabbit hole, the experimental feature nobody asked for that’s now load-bearing, or the third-party library that seemed like a shortcut and became a maintenance nightmare. You didn’t plan the detour. You just looked up one day and realized you were off the map.

The fix is the same in both worlds: know where the critical path is, check in against it regularly, and when you do take a detour, do it deliberately — not by accident.

Save Early, Save Often (Observability and Rollback)

Maybe you’re not playing with a group, but you’re playing your favorite computer RPG, like Baldur’s Gate 3 or Skyrim. Every experienced player knows: before you start a big combat, you save the game. You need that restore point. The same concepts apply to your project: You have deployments, feature flags, blue/green deploys, streaming logs, and data backups. These are your application’s save points.

But even in a table-top RPG, sometimes you need to put off a big combat or quest for later, because you’re just not ready for it. Or you go ahead and push forward, and everything goes wrong. Hopefully it’s not a TPK (total party kill), but it can be bad regardless. There are no save points in these situations, but you saw it happen, so you know why. With software, things are gonna go wrong, and sometimes you can’t restore. You need to know why. That’s where observability and logging come in.

Conclusion

Dungeons & Dragons and software development work the same way. They both reward intentional design, clear rules, balanced effort, and knowing when to improvise. The parallels between D&D and software development are clear, and it’s one that has been of great benefit to me in my own journey from developer to architect.

If you’ve read this far, congratulations! I’m granting you inspiration for your next campaign session. Tell your DM I said it’s ok.