领域中还同时存在问题空间和解决方案空间。在问题空间中，我们思考的是业务所面临的挑战，而在解决方案空间中，我们思考如何实现软件以 解决这些业务挑战。以下是如何将这两者应用到我们已经学过的知识中：
1.问题空间是领域的一部分，对问题空间的开发将产生一个新的核心域，对问题空间的评估应该同时考虑已有子域和额外所需子域，因此，问题空间是核心域和其他子域的组合。问题空间中的子域通常随着项目的不同而不同。他们各自关注域当前的业务问题，这使得子域对于问题空间的评估非常有用。子域允许我们快速地浏览领域中的各个方面，这些方面对于解决特定的问题是必须的。
2.解决方案空间包括一个或多个限界上下文，即一组特定的软件模型，这是因为界限上下文即是一个特定的解决方案，它是通过软件的方式来实现解决方案。
通常，我们希望将子域一对一地对应到限界上下文。这种做法显示地将领域模型分离到不同的业务板块中，并将问题空间和解决方案空间融合在一起。在实践中，这种做法并不总是可能的，但是通过新的努力，我们是可以做到这一点的。让我们考虑一个遗留系统，它有可能是个大泥球，其中子域和限界上下文存在相交的地方。在一个大型的企业中，通过对问题空间的评估，我们可以减少错误，进而降低成本。我，嗯可以在概念上使用两个或者多个子域来分解限界上下文，或者将多个限界上下文包含在同一个子域中。为了澄清问题空间和解决方案空间的区别，让我们来看一个例子。
让我们来看看一个大型的ERP系统提供许多模块化的业务服务，将不同的模块看成不同的子域是有好处的。比如，我们可以将库存模块和采购模块拆分成不同的逻辑子域。我们将它们分别命名为库存子域和采购子域，在下文中，我们将讲到为什么这种划分是有用的。
在我们实施某个解决方案之前，我们需要对问题空间和解决方案空间进行评估。为了保证你的项目朝着正确的方向进行，你需要先回答以下问题：
1.这个战略的核心域的名字是什么，它的目标是什么？
2.这个战略核心域中包含哪些概念？
3.这个核心域的支撑子域和通用子域是什么？
4.如何安排项目人员？
5.你能组建出一支合适的团队吗？
如果你不了解核心域的目标及其所需的支撑子域，那么你是不能从核心域中得到好处的，同时你也无法避免由此带来的陷阱。因此，我们需要全面地对问题空间进行评估，并确保所有的利益相关方在核心域的目标上都达成一致。
在了解了问题空间之后，我们来看看解决方案空间。对于问题空间的评估也是有益于理解解决方案空间的。解决方案空间在很大程度上收到现有系统和技术的影响，这里，我们应该根据分离的限界上下文仔细地思考，考虑以下问题：
1.有哪些软件资产是已经存在的，它们是可以重用的吗？
2.哪些资产是需要创建的，或者从别处获得？
3.这些资产是如何集成在一起的？
4.还需要什么样的集成？
5.假设已经有了现有资产和那些需要被创建的资产，我们还需要做些什么？
6.核心域和那些支撑项目的成功几率如何？会不会出现由于其中一个失败而导致整个项目失败的可能？
7.在哪些地方我们使用了完全不同的术语？
8.限界上下文之间在哪些地方存在概念重叠？
9.这些重叠的概念在不同的限界上下文之间是如何映射和翻译的？
10.哪些限界上下文包含了核心域中的概念，其中是有了哪些[Evans]中的战术模式？
请记住，开发核心域的解决方案是一种关键性业务投入。
