精炼是从一个混合物中分离物质的过程。精炼的目的是从混合物中提取某种特殊的物质。在精炼的过程中，可能会得到某些副产品，
它们也是很有价值的。

即使在我们提炼和创建很多抽象之后，一个大的领域还是会有一个大的模型。就是在重构多次之后，也依然会很大。对于这样的情
况，就需要精炼了。思路是定义一个代表领域本质的核心域（CoreDomain）。精炼过程的副产品将是组合领域中其他部分的普通子域
（Generic Subdomain）。

在设计一个大系统时，有那么多分布式组件，所有的都是那么复杂而且绝对须要不出差错，这使得领域模型的本质，也就是真正的商
业资产，变得模糊和不被重视。

当我们处理一个大的模型时，应该试图将本质概念从普通概念中分离出来。一开始我们举了一个关于飞空中交通监控系统的例子。我
们说飞行计划包括飞机必须遵照的设计好的路线。在这个系统里，路线好像是一个无时不在的概念。实际上，这个概念是一个普通的
概念，不是本质上的。路线概念被用在许多领域里，可以设计一个普通的模型去描述它。空中交通监控的本质在其他地方。监控系统
知道飞机要遵照的路线，但是它还会接收跟踪飞行中飞机的雷达网络输入。这个数据显示飞机真正遵照的飞行路线，而它经常和预先
描述好的有些偏差。系统不得不基于飞机当前的飞行参数、飞机特点和天气情况来计算飞行轨道。这一轨道是一个能完全描述飞机当
前飞行路线的思维路线，它可能会在接下来的几分钟里被计算出来，也可能是几十分钟，或者是好几个小时。每一个计算都有助于
决策制定过程。计算飞机轨道的终极目的是看看是不是会和其他飞机的飞行路线有交叉。在机场附近，飞机起飞或者降落时，有很多
在空中盘旋或者有其他要求。如果一个飞机偏离了它的计划路线，很有可能会和其他飞机相撞。空中交通监控系统会计算飞机的轨
道，在出现这种交叉飞行时发出警报。空中交通控制人员需要快速做出决策，改变飞机飞行路线，防止相撞发生。飞机飞得越远，计
算轨道的时间就越长，做出反应的时间也越长。根据已有的数据同步飞机轨道的模块才是这个业务系统的“心脏”。可以将它标识为
核心域。路线模型更像是一个普通域。

系统的核心域要看我们如何理解系统。一个简单的路线系统会将路线和与它相关概念看作核心域，而空中交通监控系统却把它们看作
普通子域。一个系统的核心域有可能会变成另一个系统的普通子域。正确标识核心，以及它和其他模型之间的关系是非常重要的。
精炼模型。找到核心域，发现一个能轻松地从支持模型和代码中区分核心域的方法。强调最有价值和特殊的概念。使核心变小。

将你所有的才能都投入到核心域上，不停地努力，找到一种深刻的模型，做一个足够灵活的设计以满足系统的远景。根据其他部分对
提炼后核心的支持，判断投资。

让最好的开发人员去承担核心域的任务是重要的。开发人员经常沉溺于技术，喜欢学习最好的和最新的语言，相对于业务逻辑他们更
关注基础架构。领域的业务逻辑于他们毫无兴趣可言，也看不到什么回报。还记得我们前面所谈的飞机轨道案例的要点吗？当项目完
成时，所有的知识都成为毫无意义的过去。但是领域的业务逻辑是业务的核心所在。这个核心的设计和实现中如果有了错误，将会导
致整个项目的失败。如果核心业务逻辑不起作用，所有的技术亮点都等于垃圾。

核心域的创建不是能一朝一夕完成的。这需要一个提炼的过程，另外重构在核心越来越明显之前也是很必要的。我们需要硬性地将核
心放在设计的中心位置，并划定它的界限。我们还需要重新考虑和新核心相关的其他模型的要素，也许它们也需要被重构，相关的功
能也许需要被改变等。

没有特殊的知识，模型的某些部分也会增加复杂度。任何额外的事情都会使核心域难于辨认和被理解。因为广为人知的普遍原则，或
者那些不是你首要关注但是扮演支持角色的细节都会影响模型。但是那些部分对系统功能完整性和模型的完整表达都依然是必要的。
标识出在你项目中不是推动因素的相关子域。找出那些子域的普通模型，并将它们放在不同的模型中。不要在这些模型中留下什么特
殊的印记。

一旦它们被分离开，就将对它们的持续开发的优先级调得比核心域要低，而且注意不要把你的核心开发人员分配到这些任务中（因为
它们从中获取不了多少领域知识）。另外要考虑现成的解决方案，或者那些已发布的针对普通子域的模型。

每个领域使用其他领域使用的概念。钱和它们相关的概念，比如行情和汇率，可以被包含在不同的系统里。图表是另外一个被广泛使
用的概念，就它本身而言是非常复杂，但是可以被用在许多应用中。有下面集中方法可以实现普通子域：

1. 购买现成的方案。
这个方法的好处是可以使用别人已经做好的全套方案。随之而来的是学习曲线的问题，而且这样的方
案还会引入其他麻烦。比如如果代码有凑五，你只得等待别人来解决。你还需要使用特定的编译器和类库版本。和自己
系统的集成也不是那么容易。

2. 外包。
将设计和实现交给另外一个团队，有可能是其他公司的。这样做可以使你专注于核心域，从处理其他领域的重压
下释放出来。不便的地方是集成外包的代码。需要和子域通信的结构需要预先定义好，还要和外包团队保持沟通。

3. 已有模型。
一个取巧的方案是使用一个已经创建的模型。世面上已经有一些关于分析模型的书，可以作为我们子域的灵
感来源。直接复制原有的模型不太现实，但确实有些只需要做少许改动就可以用了。

4. 自己实现。
这个方案的好处是能够做到最好的集成，但这也意味着额外的付出，包括维护的压力等。