LG 5-3: Outdated dichotomy between problem and solution space should be replaced by a distinction between domain and domain model

[mattes3]

I think, this learning goal could make a much more important and better difference than the one it tries to make. What belongs to "problem" and what belongs to the "solution" is way less important (in my opinion) than the difference between

1. the domain itself with its subdomains
2. bounded contexts and the domain models within them

I borrow from Matthias Verraes here:

A Bounded Context is a boundary around a model and its language. Within this boundary, the meaning of terms is unambiguous, well-defined and understood. The model is clear and the rules are consistent. It offers no such guarantees outside of its boundary.

• It's not a subsystem, it might be spread across multiple subsystems. It might not have a physical system, such as an Interchange context.
• It might span multiple domains or only deal with a chunk of a single domain.
• A domain might be expressed in multiple bounded contexts, e.g. if we purchase a competitor that does similar activities.

Subdomains have nothing to do with bounded contexts, except that a bounded context often results because people from the same subdomain use a certain common language.

Therefore, I propose to make the following changes to this learning goal:

The participants know the terms "problem space" and "solution space" and the difference.

Remove that.

The participants understand in the solution space "model" and "design" and how tio build them.

Replace by "The participants understand "model" and "design" and how to build them.

The participants understand how in the problem space the domain can be understood and divided into subdomains.

Remove "in the problem space"

The participants understand that language is context dependent and language is an important driver for deriving bounded contexts from subdomains.

Please, rephrase that last point completely, like this:

• The participants understand that domains and subdomains are a way to think about the problem that people have to solve.
• A Context is one part of a language where the people agree on what each term means.
• A Bounded Context is a Context that has a conceptually visible boundary. The boundary makes people understand what is "inside" and what is "outside".
• The participants understand that bounded contexts are parts of the domain model. They are orthogonal to domains and subdomains and need not have anything to do with domains and subdomains.
• The participants understand that sometimes a bounded context emerges from the terms that people use who work in the same subdomain (but this need not be the case at all).

Finally, I propose to rename this learning goal into:

• Be able to analyze a domain and derive one or more domain models from it

[mattes3]

I am pretty disappointed that this issue wasn't addressed in the May 10 release. Even more disappointed because it has received zero comments since then!

As an iSAQB CPSA-accredited trainer for DDD, I am now forced to teach the distinction between problem space and solution space, although I don't support it. Why don't we simply teach the difference between "domain" and "domain model", instead?

Here is why the distinction is misleading:

In the context of DDD, the domain model is a bridge between the problem space and the solution space. It's a conceptual representation of the business domain, but it also serves as a fou ndation for the technical implementation in the solution space. DDD emphasizes creating a shared language and understanding between domain experts and developers, which further blurs the distinction between these spaces.

In Domain-Driven Design, the creation of a domain model is a collaborative effort between domain experts and developers. It serves as a representation of the business domain and is foundational to both understanding and implementing the software. While some may argue that it leans more toward the problem space because it primarily represents the business domain, others might emphasize its importance in guiding the technical implementation in the solution space. The exact categorization can be a matter of perspective, so why make this distinction at all?

Nick Tune has written a nice article where he discusses the distinction between various DDD concepts. He recommends to avoid the notions of problem space and solution space: https://medium.com/nick-tune-tech-strategy-blog/domains-subdomain-problem-solution-space-in-ddd-clearly-defined-e0b49c7b586c

As a iSAQB CPSA trainer, I'm pretty unhappy with this learning goal in the curriculum.

I welcome your comments on this. Make me change my mind if you think so.