The 30-minute guide to Domain Driven Design: A secret weapon to solve tough problems

Using domain driven design fixes your customer perception problems, aligns technology with business, and defends against complexity.

Jul 21, 2024

In this two-part article, I’ll show how domain driven design can be your “secret weapon” to do better. There are articles out there enumerating the usual five or six technical features and benefits of DDD. I’m writing something a bit different: I want to answer the question, “What really separates DDD from other design approaches? How does it really push a team to do better?” First we’ll explore how it transforms delivery from a business and outcome perspective. In the second article, I’ll back this up with a concise introduction to its mechanics.

Why an article about domain driven design?

Domain driven design is an intrinsic part of my Delivery Playbook. Having at least a basic understanding of domain driven design (“DDD”) core concepts is critical to understanding the playbook.

My goal is to give you enough of a background to understand core concepts, whet your appetite, and convince you to take a deeper dive.

For a more in-depth understanding I’ve compiled several excellent learning resources, including textbooks and online references. I highly recommend picking one of them up — domain driven design is an excellent tool, and well worth adding to your toolkit. See the Where to learn more section, in part two of this article.

If you’re new, welcome to Customer Obsessed Engineering! Every week I publish a new article, direct to your mailbox if you’re a subscriber. As a free subscriber you can read about half of every article, plus all of my free articles.

Anytime you'd like to read more, you can upgrade to a paid subscription.

What domain driven design means to the Delivery Playbook

The Delivery Playbook (and Customer Obsessed Engineering) sets one goal above all else: Creating the highest possible value for your customer. Creating a product while simultaneously ensuring accurate delivery of what is most valuable to your customer is challenging.

That’s why the Delivery Playbook uses domain driven design as a core design process. DDD is an exploratory process that reveals what you are building — the future state product — by focusing on business activities. It pushes technology out of the discussion until it’s time to talk about technology. It involves your customer in the design process. It keeps the focus on what matters: Intended business outcomes.

The end result is a design that is customer centric. It describes a future state solution that has been hand-crafted along with your customer, focusing on what actions matter to the customer. It’s unbounded by prior technical limitations and preconceptions, and therefore free to imagine the best possible future state.

Where delivery goes wrong

Before we get into “what goes right” (and how domain driven design helps achieve “right”), let’s talk about some of the problems teams experience. Then we’ll explore how domain driven design protects against those problems.

Not involving your customer every step of the way

Too many projects go off the rails because they’ve lost touch with their customer. This happens at different junctures, leading to different types of failure.

The most obvious mistake is not involving your customer and product’s end-user in the design phase. Without soliciting customer desires, problems, solutions, and feedback throughout the design it’s inevitable that you’ll end up with a product that doesn’t align perfectly with those expectations.

Other frequent failures stem from customers and delivery teams becoming misaligned about expectations. This happens when the technical team and the customer, end-user or business team diverge and start to anticipate different outcomes. Those differing opinions could be about feature and function, or performance metrics, or timing.

Similarly, failing to keep everyone aware of progress, changes in scope or delivery, or even the eventual cost of operations will also lead to problems.

Talking about technology too soon

From a design perspective, introducing technology into the design conversation too early leads to another set of problems.

One mistake is to limit a design based on pre-existing ideas or assumptions rooted in technology. For example, making the assumption that your design must use the same database (or, for that matter, that you even need a database).

It’s easy to impose limitations on product design. This is especially true if we get stuck thinking, “that’s not possible with the technology we use.” Likewise, it’s easy to impose specific design outcomes because “this is the way it works (technologically).” We end up creating arbitrary limits.

For instance, assuming that the new user interface will use a web browser limits us to certain assumptions about the user experience. Newer or just different technologies often free us from previous limitations about technique, processing speed, linear design patterns, workflows, and other capabilities.

Reinventing the past

Just as thinking about technology can limit our design, focusing too much on legacy products can do exactly the same thing. Using an existing system as a model for the future can lead to reinventing the problems of the past — not always, since we’ll be trying to fix the major known limitations. But, what about the unknown limitations? If we use the existing product or technology as a basic blueprint for the future we can inadvertently recreate ways of working that could be improved.

It’s a little bit like “cargo cult” thinking. Since we do it this way, and it seems like “this way” works, then we’ll just keep doing it the same way. That might prevent us from imagining better ways of working, unless, as Richard Feynman points out, you “report everything that you think might make it invalid — not only what you think is right about it.” I think DDD is great, because it pushes us to do that.1

Building more than you need

Over-design is another problem that often crops ups. In this context, “over-design” means creating functions, features, and whole products that are more elaborate than needed (or even completely unnecessary).

This can sometimes happen if we design based on an existing product — we might end up “accidentally” recreating features that just aren’t used or needed anymore. Less obvious is over-design stemming from a disconnect between technology and the business (or the customer).

Technologists love to design elegant solutions. Sometimes we spiral out of control, essentially building a solution that is more robust or feature-rich than it needs to be. I recall working with a team to design an ETL (data loading and transformation) feature. It had to intake data from an external source, clean it up, and inject it into the system. The team had designed an elegant and very nicely automated, although complex, system for handling all the transformations — but in the end, the customer didn’t need it. It was basically a one-time load, rare enough that the customer was perfectly happy making the transformations manually.

Measuring the wrong things

Sometimes disconnects between the technology team and the business (and customer) arise because there is misalignment on what matters. I’ve seen so many teams measure the wrong things. The obvious misstep is focusing on “sprint velocity” instead of “value delivered,” but that itself is an overly generalized example. There’s nothing wrong with measuring velocity, we just have to recognize velocity doesn’t provide any indication of value delivered.

Ultimately, the customer cares about very specific business drivers. Those drivers are the foundation on which the entire product’s value proposition stands.

There are a lot of things that can be measured when delivering a product, but if the right things aren’t being measured — specifically, metrics that prove the value proposition — it’s likely the wrong product gets delivered. It’s critical that product design identifies not only the features that deliver value, but also how to measure and verify that expectations are met.

How to achieve “right:” The value in domain driven design

Domain driven design was originally conceived by Eric Evans in his book of the same name published in 2003. Since then it has grown to become a mature, respected and widely adopted design practice, proving particularly effective in large scale, multidiscipline projects. Its use in event streaming architecture is nearly ubiquitous.2

In the second part of this article, I’ll talk about the major components and activities that make up domain driven design. Before getting there, let’s look at how DDD solves the challenges introduced above, and briefly introduce a few of its other advantages.

If you use the referral button below, you’ll earn free premium access to Customer Obsessed Engineering. Just three referrals will earn a free month!

Refer a friend

Improving collaboration and alignment

One of the greatest strengths domain driven design offers is strong collaboration and team alignment. The design process — especially early in the design cycle where small changes yield big impacts — relies heavily on whole team involvement.

Domain driven design uses exploratory workshops and design sessions where technology as well as customer, business and domain expertise is wielded collaboratively. For example, event storming is an exercise where the business owners that “live and work” in the business domain collaborate with technology to model how the business operates. It’s not to model how technology mimics the business, but instead exactly the events and actions a business cares about. It does this by recording the day to day work of individuals; in other words, what they actually do to get their job done. Nothing else finds its way into that conversation.

These highly interactive workshops lead to greater mindshare, and greater alignment. That alignment is evidenced in the quality of the design assets, and the brevity of those assets.

Simultaneously, the technology team develops a penetrating understanding of business operations, something that is often lacking in other approaches. That understanding leads to higher quality work product.

Avoids entangling technology and business choices

Another strength comes from the sheer focus on events, and not technology, until the time is right. This is evidenced by how the early design activities — like event storming — explicitly don’t talk about technology choices.

The reasoning is simply this: First, we need to model the ideal future state of a business. What is the unbounded, imagined, and most desirable product? How can we do our work more efficiently, more effectively, more enjoyably? These ideas are elicited by allowing individuals to co-create a future without imposing limits.

Technology can be a limiting factor, and often is. Therefore understanding the best possible future state first is important. If we limit our imagined future by imposing specific technical choices, we’ll never design the most desirable product. Instead, we’ll design the “most potentially limited product,” bound by specific assumptions.

First, let’s define where we want to be. Later, as domain driven design moves from event storming into more technical design phases, we’ll have plenty of opportunity to make technology choices. Those choices might limit the future state — or they might open up new possibilities.

Prevents reinventing old problems

Too many systems (meaning tools, processes, ways of working) exist merely because that’s the way it’s done. If we pay too much attention to existing products, we run the risk of repeating past mistakes. We could do it inadvertently, by simply copying something that seems to work pretty well… without realizing that someone, somewhere, has some great ideas about how to do things better.

Domain driven design pushes the team to bring those ideas to the fore. This happens during user journey mapping and event storming, since both of these activities avoid talking about past systems (as much as possible) and focuses on imagining an improved future state.

None of this is to say prior work, existing product, or lessons learned are not leveraged. It’s merely that guardrails are put in place to make sure we don’t dwell too much on past decisions.

Measuring the right things to ensure success

While not an explicit practice in domain driven design, measuring the right things to make sure you are delivering successfully is crucial. The Delivery Playbook does this by leaning heavily on DDD.

As we’ve discussed, one of the challenges many projects face is staying closely aligned with customer value, and measuring that value as it is delivered. Domain driven design is well suited to isolating specific value, making it manageable, and turning complex problems into something easier to reason about. Part of that includes figuring out exactly what we can measure to ensure success.

Context mapping is one tool DDD employs to break those large, complex problems into smaller, more well-isolated pieces. This, in turn, makes it possible to think clearly about how to measure the success of those pieces. To do this, we turn to objectives and key results, and then throughout the playbook we keep checking to make sure we stay aligned with those goals.

Defending against complexity

A core principal of DDD is breaking a problem down into it’s different business domains. These domains may be further decomposed into contexts, each of which is a self-contained representation of some unique value proposition — some “way of working” distilled into a finite business process. Each tends to be small, very specific, and therefore pretty easy to reason about.

One benefit of this approach is that similar ideas become co-located. Business functions that do very similar things are aggregated into the same context — which avoids spreading logic throughout a system, the “spaghetti code” often referred to when thinking of big, monolithic, old-world systems. And where there are dependencies between contexts, DDD models these dependencies well.

This clean separation of concerns fuels a lot of benefits: Technical benefits, such as independent scalability, and operational benefits, such as allowing different teams to work effectively in parallel.

Communicating better with your customer

Domain driven design is largely about identifying contexts and recognizing that each context is, in fact, a different part of the business. One of the most important things we realize in analyzing a business in this way is that different language is used across different operations.

That may seem a bit obvious, but there’s an incredibly important observation here that is often missed: Different parts of a business use words differently. Think about a bank, for instance. Depending on what department you’re in, the word “account” could mean very different things. For example, it may refer to securities (a trading account), personal savings (a traditional equity account), a leveraged debt (a loan account) or just your authentication and personal identity (your login account). If we bring actuaries or insurance into it, it gets even more complicated.

Throughout DDD we focus on developing clear ubiquitous language and defending the language of a specific context. That means creating clear designs (and code!) that are free of ambiguity, with clear boundaries between these different parts of the business. You eliminate ambiguous communication, creating a system that you and your customer can reason about without making mistakes.

Not missing anything important

Finally, DDD is mature. It is a thorough design approach that encompasses the “big picture,” and works down to the technical minutiae. As a proven system that has evolved for a few decades, we can count on it to give us a clear roadmap and well-defined guardrails to make sure we think about all the important details.

DDD is surely not the only approach out there. It is, however, one of the few approaches that tackles the problem of establishing and protecting customer value head-on. It is also one of the best tools to turn large, complex problems into manageable smaller problems.

In part two of this article, we’ll dive into the actual mechanics of domain driven design, and how the Delivery Playbook leverages it. We’ll wrap up with a list of resources your team can use to quickly get up to speed with DDD.