From strategy to code: How the discovery process changes thinking about DDD

You probably associate DDD mainly with tactical patterns: aggregates, entities, value objects. You implement them, you write code, but do you always know what problem you are actually solving? What if the best code is no code at all? I would like to tell you how the discovery process is at the heart of DDD and how it allows us to go beyond just writing code to create truly valuable solutions.

Change of perspective: from tactics to strategy

We often make the mistake of starting our adventure with DDD with implementation. We fall into the trap of thinking that DDD is a new library, framework, or coding style. Meanwhile, the most important part of DDD is strategic and happens outside the code editor. This is when we talk to domain experts, ask questions, and try to understand why a given problem exists in the first place.

Instead of immediately sitting down to write code, take the time to explore. It is at this stage that you may find that complex software is not necessary at all. Perhaps a simple spreadsheet will solve a problem that rarely occurs and does not require complex infrastructure – because, as they say, “the best code is no code.”

Language pitfalls and how to avoid them

One of the main ideas behind DDD is “ubiquitous language.” The idea is that everyone, from engineers to business experts, should use the same language to describe the domain. The problem arises when, instead of building a common language, we try to translate business jargon into technical jargon, or worse, we force the business to use our technical terms, such as database table names. This is a surefire recipe for misunderstanding.

Imagine: if you have a users table in your project, and in business language we talk about “customer,” “employee,” and “partner,” then using the term user in the code is confusing. A ubiquitous language evolves and requires constant refinement in an iterative process—it's like a living organism.

Discovery in practice: avoid the “what if?” trap

During the discovery process, you naturally ask questions like “what if...,” right? “What if a customer wants to return a product they've already shipped?” “What if the transaction doesn't go through?” Such scenarios may seem far from the point, but they actually help you find common denominators that simplify the architecture. For example, instead of creating dozens of classes for every possible case, you can find one more general pattern that will cover all scenarios.

The same applies to databases. Instead of building specific tables for each case, you can define more general structures that still make sense for the domain.

This approach allows you to build a solid foundation that will be scalable and easy for the whole team to understand. Remember, don't stop asking questions and documenting your decisions so that they will be understandable in the future as well.

Change must come from above... and from below

Introducing strategic thinking about DDD in an organization that is used to writing code right away is quite a challenge. Bottom-up change, i.e., starting with the development team, is natural but difficult. It requires building relationships with other teams and proving that this approach makes sense.

Documentation, diagrams, and joint meetings are very helpful here. They show that the discovery process is not a waste of time, but an investment in knowledge that pays off. It is worth remembering that acquiring knowledge about the domain never ends. It is a continuous process that requires regular meetings and updates to understanding, because the business and its environment are constantly changing.

Summary

The discovery process is at the heart of Domain-Driven Design. It allows you to go beyond the technical layer and truly understand the problem you are solving. It is during this process that you learn what tools the business needs and how to create software that not only works but also makes sense. Remember, the best solutions often come from conversation, not code.

Happy discussing!