The Problem with Code Reuse - Why DRY Isn't Always the Answer

(This was episode #11 of my Event Modeling & Event Sourcing newsletter)

This week’s edition is arriving a little later than expected, but I hope it’s worth the wait! Today, we’ll dive into the topic of code reuse and why, contrary to popular belief, it’s often not the best idea.

The discussion began with a common question: “Should we reuse simple classes like DTOs across the system?”

If you had asked me this 10 years ago, my answer would have been an enthusiastic “Yes! Keep it DRY. Reuse is good!” But today, my perspective has shifted. Let me explain.

Why Code Reuse Is Tricky

For many of us, the principle of reusing code is ingrained—perhaps from university, where it’s still taught as a best practice. So, when we encounter simple value classes like Email, Address, or Location, it feels natural to think: Why not reuse them? They rarely change, right?

Well, here’s my answer: Don’t, if there is not a very good reason.

I know this sounds controversial. In fact, during the discussion, someone quickly raised the usual counterargument:

“If we don’t reuse classes, won’t we end up with mapping chaos and duplicate code everywhere?”

A Real-Life Story

To illustrate my point, here’s an excerpt from chapter 10 of my book, Understanding Event Sourcing. It’s based on one of my first projects—a classic example of how reusing value classes can backfire.

Before you dive into this topic - there is a new Online Course “Implementing Eventsourcing”, that will guide you step by step through this process. Find more details at the end of this article.

Imagine you’re faced with a choice:

1. Create a central location for these reusable classes and share them across the project (from domain to presentation).
2. Reimplement them in each module, risking what I call Mapping Hell—most of your code ends up translating from one context to another.

Which is the smaller problem?

The Problem with Reuse

Let’s take a Location class as an example. It contains latitude and longitude—seems simple enough to reuse, right? Not so fast.

By reusing the Location class, you’re assuming that its definition is consistent across the entire system. For some modules, this might hold true. But in others, “location” might represent something completely different, like a physical address.

Now consider an Address class. At first, it might seem reusable too. But what happens when one module needs to add a companyName field to support business addresses? Suddenly, every module in the system inherits this new field—even those that don’t care about it. This creates strong coupling between modules.

The biggest issue? Where do you draw the line? Is Location reusable but not Address? How do you decide—on gut feeling?

My Approach: No Coupling Between Modules

My approach is simple: Prevent coupling at all costs. Code reuse or DRY is not my priority.

So, I never reuse value classes across slice- or module-contexts. Ever. It might seem extreme, but this clear guideline ensures that vertical slices remain independent. And the freedom this approach brings is worth it.

But What About Mapping Hell?

Yes, at some point, you need to translate between contexts. But if you’re working with Event Sourcing, you’re already projecting data from your event store to your target models. There are no global assumptions—you simply build the models you need.

In this sense, CQRS complements Event Sourcing beautifully. You store data one way but read it in multiple ways. If you find yourself constantly mapping the same information between layers, it’s worth revisiting your system design. Mapping should not dominate your codebase.

Food for Thought

As always, this email reflects how I personally approach a common challenge. My solution may not be the best for everyone, but it offers a perspective that I hope you find thought-provoking. It’s the kind of discussion that’s best enjoyed over a few beers.

Want to see this in action?

Join the free newsletter to get Event Modeling & Event Sourcing once per week to your inbox.

If this topic resonates with you, there is a full recording of my Webinar: Full Circle: Plan, Build, and Verify

We’ll cover the entire process—from requirements to prototype to code—in just 90 minutes. You’ll see exactly how I work, and the Q&A at the end will be a perfect opportunity to ask your questions.

Want to practice your skills in a safe environment?

The Online Course “Implementing Eventsourcing” gives you exactly that. It’s a perfect companion to the Book “Understanding Eventsourcing”!

Everything I know about Evenet Modeling & Event Sourcing in one course.

Martin Dilger

Related Articles

The Code Reuse Problem

Understanding the hidden costs of code reuse

Software Design • November 2025

10 Learnings from 10 Years of Microservice Development

Hard-won lessons from a decade of building distributed systems

Microservices • November 2025

AI Agents, Brooks' Law, and Coupling

How AI agents change the dynamics of software development

AI & Software • November 2025