Problem-driven vs Domain-driven

Marco Heimeshoff responded to the blog post about Problem-Driven Design. He triggered an interesting discussion in LinkedIn and asked in the end:

... where do you see the difference in Problem Driven Development and DDD?

Here is my take.

Domain-driven design

Domain-Driven Design (DDD) works with established domains. It is driven by the domain, as the name implies. We work with stakeholders and domain experts to reach shared understanding, to clarify a map, manage complexity and deliver solutions.

In the words of Marco:

The major focus of the Domain-Driven Design community has been on experimenting, developing and adopting methods to understand the purpose-space of the customer and all the stakeholders needs.

The map may be uncertain, but the business already exists, and it is a viable one. The exploration happens within these boundaries and is directed inwards.

From this perspective, the problem space is defined. DDD is well-equipped with the tools to tackle complexity and deliver business value in such environment. DDD helps to build the best solution possible.

Problem-driven design

Situation can also be completely different. Tom Janssens from the Belgian DDD community expressed this well:

In DDD we tend to assume that the problems the customer share are a given. When you are running a business this turns out to be not true...

Imagine that you need to write a new book, build a sustainable product or assist a company in exploring new business opportunities. The domain is uncertain. There is a myriad of options to choose from. Some would be viable and some would not. It is chaos, full of possibilities.

The purpose of problem-driven design is to venture out into this completely new "there be dragons" territory and establish a new viable domain.

"Viability" could mean anything: support a family, build a reputation, do social good, create a big business. These are the constraints.

Given these constraints, we talk with potential customers, discover their problems, and dig into these discoveries.

We identify and pick the problems that could be solved in a viable way. Then we shape a solution and find the shortest path to validate it.

The earlier we find flaws in our approach - the better. This means, we save hours and dollars from the wrath of reality and get to work on a new problem-solution.

At early stages we could employ methods from the lean startups, iterative development, data-driven product design, and the art of conducting customer interviews.

In short:

Coding should start after the solution design. Design should start after talking to people and identifying the problems. All three should iterate.

If all that works out - we may have just carved a piece of reality into a brand new domain. Domain-driven design could assist to grow it further.

Virtual Sales Lab by Tom Janssens would be a very good example here. The product is about building sales and marketing tools that leverage 3D technologies. The domain itself didn't really exist a decade ago. It is growing now. In the next decade, 3D sales might evolve into a well-known and established domain.

Why such optimism? Aren't current 3D solutions a bit ugly?

Younger generations prefer to perceive the world through 3D.

Huge parties in Fortnight, kids of all ages playing Minecraft, tech advancements are tell-tale signs within the problem space that show the inevitability. The solutions aren't defined, but deep currents within the problem space will lead to something.

Update

There is a follow-up article: Solving the wrong problem.

Published: January 02, 2022.

Next post in Opinionated Tech story: Solving the wrong problem

🤗 Check out my newsletter! It is about building products with ChatGPT and LLMs: latest news, technical insights and my journey. Check out it out