第十五章 精炼

精炼的主要动机是把最有价值的部分提取出来，真实这个部分使我们的软件区别于其他软件并让整个软件的构建物有所值，这个部分就是CORE DOMAIN

简介：领域模型的战略精炼包括以下部分：

• 帮助所有团队成员掌握系统的总体设计以及各个部分如何协调工作
• 找到一个具有适度规模的核心模型并把它添加到通用语言中，从而促进沟通
• 指导重构
• 专注于模型中最有价值的部分
• 指导外包、现成组件的使用以及任务委派

一、模式：CORE DOMAIN

• why?在设计大型系统时，有非常多的组成部分--它们都非常复杂且对开发的成功也非常重要，但这导致真正的业务资产--领域模型最为精华的部分被掩盖和忽略了。稀缺的高水平的开发人员把工作重点放在技术基础设施上，或者去解决不需要专门的领域知识就能够理解的领域问题。
• 对模型进行提炼。找到CORE DOMAIN并提供一种易于区分的方法把它与那些起辅助作用的模型和代码分开。最有价值和最专业的概念要轮廓分明。尽量压缩CORE DOMAIN。让最有才能的人去开发CORE DOMAIN，并根据此要求进行相应的招聘。在CORE DOMAIN中努力开发能够确保实现系统蓝图的深层模型和柔性设计。仔细判断任何其它部分投入，看它是否能够支持这个提炼出来的CORE
• 选择核心。我们需要关注的是那些能够表示业务领域并解决业务问题的模型部分。方法是建立一支由开发人员和一位或多位业务领域专家组成的团队。自主开发的软件的最大价值来自于对CORE DOMAIN的完全控制。一个设计良好的框架可能会提供满足于你的专门使用需求的高水平抽象，它可以节省开发那些更通用部分的时间，并使你能够专注于CORE。

二、精炼的逐步提升

• 一份简单的DOMAIN VISION STATEMENT（领域愿景说明），很少的投入，表达了基本概念和它们的价值。HIGHLIGHTED CORE（突出核心）可以增进沟通，并指导决策制定，只需很少的改动甚至无需改动。
• 重新打包出一个SEGREGATED CORE（分离核心），可以使这个核心清晰可见，并且促进将来在CORE模型上的工作。
• ABSTRACT CORE（抽象内核），它用最纯粹的形式表达了最基本的概念和关系。
• 领域模型的连续精炼将为我们创造一项资产，使项目进行得更快，更敏捷，更精确。

三、GENERIC DOMAIN

• why？模型中充斥着大量众所周知的一般原则，或者是专门的细节，这些细节并不是我们的主要关注点，而只是起到支持作用。然而它们无论是多么通用的元素，它们对实现系统功能和充分表达模型都是十分重要的。但是要小心不要因此污染CORE DOMAIN
• how？识别出那些与项目意图无关的内聚子领域。把这些子领域的通用模型提炼出来，并放到单独的model中。把它们分离出来以后，在后续的开发过程中，它们的优先级低于CORE DOMAIN，不要派核心开发人员来完成这些任务。可以考虑为这些GENERIC DOMAIN使用现成的解决方案或“公开发布的模型”。
• 开发这样的软件包（模块）有以下接种选择：使用购买实现好的解决方案或者开源代码；使用公开发布的设计或模型；把实现外包出去；内部实现。
• 通用不等于可重用，不因该把专用的模型元素引入到通用的子领域中，也不必开发出“万能的模型”
• 项目风险管理：有些项目技术风险更大，有些项目领域建模的风险更大。

四、DOMAIN VISION STATEMENT

• why？它关注的重点是领域模型的本质，以及如何为企业带来价值。项目开发阶段，管理层和技术人员都可以直接用领域愿景说明来指导资源分配、模型选择和团队成员的培训。如果领域模型为多个群体提供服务，那么此文档还能够显示出它们的利益是如何均衡的。
• how？写一份CORE DOMAIN的简短描述（大约一页纸）以及它们将会创造的价值。那些不能将你的领域模型与其它领域模型分开的方面就不要写了。展示出领域模型是如何实现和均衡各方利益的。这份描述要尽量精简。尽早写出来，随着新的理解随时修改它。

五、模式：HIGHLIGHTED CORE

• 提炼文档：编写一个简短的文档，用于描述CORE DOMAIN和CORE元素之间的主要交互过程。要注意的问题是：1、文档得不到维护；2、文档可能没有人阅读；3、文档可能达不到简化复杂性的目的。
• 标明CORE：把模型的主要存储库中的CORE DOMAIN标记出来，不用特意去阐明其角色。使开发人员容易知道什么在核心内，什么在核心外。
• 把精炼文档作为过程工具：如果精炼文档概括了CORE DOMAIN的核心元素，那么它可以作为一个指示器--用以指示模型改变的重要程度。模型或代码的修改影响到精炼文档时，需要与团队其它人员一起协商。但对精炼文档作出修改时，需要立即通知所有成员，把新修改的文挡分发给他们。

六、模式：COHESIVE MECHANISM

• why？计算有时很复杂，使设计变得膨胀。机械性的“如何做”大量增加，把概念性的“做什么”完全掩盖了。为解决问题提供算法的大量方法掩盖了那些用于表达问题的方法。
• how？把概念上的COHESIVE MECHANISM（内聚机制）分离到一个轻量级框架中。用一个INTENTION-REVEALING INTERFACE来暴露这个框架的功能。领域中的其它元素可以专注于如何表达问题（如何做）了，而把解决方案的复杂细节（如何做）转移给了框架。
• GENERIC SUBDOMAIN与COHESIVE MECHANISM比较：动机相同，都是为CORE DOMIN减负。G是是以描述性的模型作为基础的，它用这个模型表示出团队会如何看待领域的某个方面。C并不表示领域，目的是解决描述性模型说提出来的一些复杂计算问题
• 特殊情况，MECHNISM是CORE DOMAIN的一部分。因为此时MECHANISM本身就是专有的并且是软件的一项核心价值。

七、通过精炼得到声明式风格

• 如果领域中那些起到支持作用的部分提供了一种简练的语言，可用于表示CORE的概念和规则，同时又能够把计算或实施这些概念和规则的方式封装起来，那么CORE DOMAIN的重要部分就可以采用声明式设计。

八、模式：SEGREGATED CORE (隔离核心)

• why？模型中的元素可能一部分属于CORE DOMIN，而另一部分起支撑作用。核心元素可能与一般元素紧密耦合在一起。CORE的概念内聚性不是很强，看上去也不明显。这种混乱性和耦合抑制了CORE。易开发出脆弱的设计。
• how？对模型进行重构，把核心概念从支持性元素中分离出来，并增强CORE的内聚性，同时减少了与其它代码的耦合。把所有通用元素或支持性元素提取到其它对象中，并把这些对象放到其它包中--即使这会把一些紧密耦合的元素分开。
• 步骤：1、识别出一个CORE子领域；2、把相关的类移到新的model中，并根据这些类的有关概念为模块命名。；3、对代码进行重构，把那些不直接表示概念的数据和功能分离出来；4、对新的SEGREGATED CORE MODEL进行重构，使其中的关系和交互变得简单、表达更清除。5、对另外的CORE子领域重复这个过程。

九、模式：ABSTRACT CORE

• why？即便是CORE DOMAIN模型也会包含太多细节，以至于它很难表达出整体视图。但不同MODEL的子领域之间又大量交互时，那么需要在MODULE之间创建很多引用，这在很大程度上抵消了划分模块的价值；那么就要间接的实现这些交互，而后者会使模型变得晦涩难懂。
• how？把模型中最基本的概念识别出来，并分离到不同的类、抽象类或接口中。设计这个抽象模型使之能够表达出重要组件之间的大部分交互。把这个完整的抽象模型放到它自己的MODULE中，而专用的、详细的实现类则留在子领域定义的MODULE中。