Hi Alexey. Thanks for jumping into this discussion and providing another expert and welcome perspective.

The problem with problem/solution space is that there is little agreement on what these concepts mean and what is in each space. I’ve seen many drastically different opinions (check out the linked github discussion for more context).

I find it hard to relate to “the domain is the problem space and it’s the problem we’re trying to solve with software”. When we build software, we are changing the problem space. This makes “bounded context is the solution space” hard to logically follow. I don’t see how the domain can just be there irrespective of what we do. Do you have an example? When we build solutions we change the domain (meaning bounded contexts must also live in the solution space as well once they have solved a problem).

I also think that the DDD definition implies core is part of the solution (this is from the DDD reference guide):

Boil the model down. Define a core domain and provide a means of easily distinguishing it from the mass of supporting model and code. Bring the most valuable and specialized concepts into sharp relief. Make the core small.

In my opinion, Landscape (from the Wardley Cycle) is a much better model. (Sub)domains are part of the landscape. When we solve problems our solution changes the landscape. When we explore models, we are exploring possible new versions of the landscape. To me this is much clearer and a much richer model (purpose, doctrine, landscape, leadership). Give it a try, you might like it :)