第九章 将隐式概念转化为显示概念

一、若开发人员识别出设计中隐含的某个概念或是在讨论中受到启发而发现一个新的概念时，就会对领域模型和相应的代码进行许多转换，在模型中加入一个或多个对象或关系，从而将此概念显示地表现出来。

怎么发现呢？

1、倾听领域专家的语言，有没有一些术语更简洁地表达某个复杂的概念。

2、检查不足之处

3、思考矛盾之处

4、查阅相关书籍，学习相关领域知识，和专家的知识相对照。

5、不断尝试、试错，找到足够清晰而且实用的概念。

二、如何为不太明显的概念建模

1、显式的约束，例如原本的固定规则用逻辑判断表示，可以改为将约束的判断逻辑放到方法中，用方法名来表达约束的意义。原本虚拟的概念就“有名有姓”了。升级版的是将约束提取到显示地对象中。

2、将过程建模为领域对象，用对象来封装过程，我们只需考虑对象的业务目的或意图。

3、模式：SPECIFICATION

谓词是指计算结果为“真”或假的函数，并且可以使用and、or操作符连接起来表达更复杂的规则。

业务规则通常不适合作为ENTITY或者VALUE OBJECT的职责，而且规则的变化和组合也会掩盖领域对象的基本含义。但将规则移除领域层的结果会更糟糕，这样领域代码就不再表达模型了。逻辑编程提供了这样一种概念，将“谓词”这个可分离可组合的规则对象，但是将这种概念用对象完全实现是很麻烦的。

新的对象就是一个规格，SPECIFICATION(规格）中声明的是限制另一个对象状态的约束，被约束的对象可以存在也可以不存在。规格的用途是测试任何对象以检验它们是否满足指定标准。当规则很复杂时，可以扩展这种概念，对简单的规则进行组合。SPECIFICATION将规则保留在领域层，由于规则是一个完备的对象，所以这种设计能更加清晰地反映模型。

4、S的应用和实现：验证对象；选择（查询）一个特殊的对象；创建对象，创建或重新配置满足S的全新对象或对象集合。甚至可以使用描述性的S来生成器的接口，其中可包含创建对象的过程或指令集。

三、通过可工作的原型来摆脱开发的僵局

有时一个团队需等待另一个团队提交代码后才可以继续工作，而这两个团队都要等到代码完全整合后才可以测试组件或从用户那里获取反馈。这种僵局通常可以通过关键组件的模型驱动原型来缓解，即使原型并不满足所有需求也可以。当实现与接口分离时，只要有可以工作的实现，项目就可以并行开展下去。实际成熟的时候，可以用更为高效的实现来替代原型，同时，系统中其它部分也能在开发期间与原型进行交互。

 

四、个人感悟：方法、对象、接口，一步步层层封装，来表达隐式的概念。同时使不同开发团队解耦。高效，代码可读性增强。

《领域驱动设计》，真的是强！！！