通常认为解决方案空间是绑定到问题空间的上下文（这就形成了有界上下文），问题空间是真实存在，而解决方案空间是人的主观设计实现。
请注意：这里潜台词引入了主观和客观的区别，问题空间是客观真实，解决方案是人的主观，看上去解释得非常完美，而且很有逻辑，但是最大漏洞是：问题空间可能并不是真实的存在，而是一个人脑袋里认为的那个问题空间，如果两个人认为的问题空间不同，谁来做裁判判断谁的问题空间才是真实的呢？所以，这段话的问题是把人类自己居于上帝位置上思考，置身于时空之外使用主观和客观二分法，这种不考虑人类自身参与影响的哲学是相当愚蠢的。
其实，问题空间等同于康德的物自体，真实问题空间是我们无法全面了解掌握，我们获得需求的方式通常是从用户自己的解决方案还原问题空间，不是用户自以为是用解决方案替代问题，而是他认为的问题空间其实通过其主观设定的上下文已经被解决方案影响了，掺入了个人偏见，没有人可以扮演上帝公正客观地还原问题空间。（反过来设想：如果我们能客观公正在短时间内掌握问题空间，还会遭遇需求变化导致措不及防吗？软件工程是一个学习过程，代码只是学习的副产品）
从这个意义上看，问题空间和解决方案空间的划分是一个伪命题，只是一种初级认识手段而已，在真实实战中是无法凭借这种方法实操的。引入这两个概念只会增加DDD术语的复杂性，反而导致初学者望而却步，甚至误导初学者，取而代之应该使用领域事件/业务事件，业务事件代表问题空间发生的人们可以感知的确实动作，也就是说，问题空间是难以全面认识的物自体，但是见微知著，可以通过领域事件获得线索，这也是事件风暴建模和事件建模的来由。
参考：
幽默：为什么DDD的Bounded Context翻译为"有界上下文"？
软件设计的目标是创建适合人类思维的片块 - KentBeck
业务事件的重点是什么？
如何实现DDD事件建模的详细步骤