领域驱动设计——模型

一、模型的表示

表示领域模型的设计元素包括实体 （entity）、值对象 （value object）、领域服务 （domain service）。领域层的设计必须限定在这些对象中，否则就有可能使得领域层和其它层的限界模糊，也就是软件设计中的无法解耦，导致领域层设计的混乱，进而造成整个领域层设计的失败。
1、Entity
主要由标识定义的对象被称作ENTITY。ENTITY（实体）有特殊的建模和设 计思路。它们具有生命周期，这期间它们的形式和内容可能发生根本改变，但必须 保持一种内在的连续性。为了有效地跟踪这些对象，必须定义它们的标识。它们的 类定义、职责、属性和关联必须由其标识来决定，而不依赖于其所具有的属性。即 使对于那些不发生根本变化或者生命周期不太复杂的ENTITY，也应该在语义上把它 们作为ENTITY来对待，这样可以得到更清晰的模型和更健壮的实现。
2、value object
用于描述领域的某个方面而本身没有概念标识的对象称为VALUE OBJECT（值对象）。VALUE OBJECT被实例化之后用来表示一些设计元素，对于这些设计元素，设计者只关心他是什么，而不关心它们是谁。换句话说，对于一个实体对象，脑袋上挂着一个工号，对绝大多数应用来说并没有认知上的意义。映射到现实世界来，它只是一个代号。但值对象所描述的这个实例拥有的元素，可以让设计者向使用者展示它的具体的能力。
更为需要注意的是，值对象在不同的设计中其表现的元素可能有所不同，一个元素，可能在一种设计中是值对象，但是到另外一种设计中，可能就是一个实体。

3、domain service
在某些情况下，最清楚、最实用的设计会包含一些特殊的操作，这些操作从概念上讲不属于任何对象。与其把它们强制地归于哪一类，不如顺其自然地在模型中 引入一种新的元素，这就是SERVICE（服务）。SERVICE是作为接口提供的一种操作，它在模型中是独立的，它不像ENTITY和 VALUE OBJECT那样具有封装的状态。SERVICE是技术框架中的一种常见模式，但它 们也可以在领域层中使用即它强调的是与其他对象的关系。好的SERVICE有以下三个特征：
与领域概念相关的操作不是ENTITY或VALUE OBJECT的一个自然组成部 分；
接口是根据领域模型的其他元素定义的；
操作是无状态的。
领域的服务其实就是对实体、对象间的动作、行为的一种抽象，这和上面体现出接口的形式就可以看得很清晰了。软件的接口一般就是操作的接口。不过这里有一个小问题，就是如何区分领域层的Service和应用层的Service，不要混淆二者。

二、关联

其实学习过UML的都明白，关联是个什么东西。现在常说的万物互联，就是要万物都关联起来。可是在设计者的眼中，这是最糟糕的现象。同样，在领域设计过程中，需要处理对象实体间的关系，这些关系就是关联。在设计过程中，需要对整个模型进行描述，那么在拥有了模型的元素和元素间的关联就可以比较清楚的对模型设计有了一个更抽象的把握，而不至于陷入细节的迷雾之中。但是需要注意的是，在MDD中，关联本身并不是一个模式。但为了更好的进行设计需要注意几个方法：
1、限定关联的单调性即遍历的方向。
2、要减少关联，也就是软件设计中的解耦，降低耦合性在哪里都是一个重要的方法。
3、增加限定符，形成关联的弱化。
这些方法其实都很好理解，如果循环关联或者网络式关联，那么在软件设计中就会遇到不少的麻烦事儿。同样，关联越少，意味着设计中的耦合度越低，而增加限定符，就可以把设计的难度降低很多，甚至是一个维度。

三、模型的范式

提到范式，就得首先明白什么叫范式？不知道大家有没有看过青铜器如何铸造而成的。青铜器的铸造，多种范式制造，比如失蜡法、范铸法等等。更容易理解的是小孩子们的泥范，有一个小盒子，塞进去泥土或者蜡敲出来就是一个漂亮的图形。所有的抽象的东西不是人的大脑天生出来的，都是从现实世界映射抽象出来的。模型设计也是如此。
在目前面向对象做为一种范式就是非常流行的，当然，面向服务和面向接口同样也在实际中应用很广。而在关系型数据库中，关系范式应用普遍。诸如此类，这时候，设计者会发现，一个设计往往用一种范式无法解决所有的问题，那么必然会引用多种范式混合设计。而在DDD设计者的眼中，坚持以对象范式为主就非常重要，但这并不意味着对象就是一切。在根据实际情况，在不同的非对象的情况下，使用更符合实际的具体的范式来解决设计问题才是关键。将它们有机的结合起来，才会形成更好的设计模型，比如将业务规则引擎或工作流引擎这种非对象模型，就可以通过封闭适应的范式，混合范式设计。
需要明白的是，模型是一种抽象，是一种更符合实际情况的抽象。所以无所谓哪一种放之四海皆准的范式。只要能更好的表现实际情况，就是一种好的设计范式（包括混合范式）。当使用混合范式时，需要以下几个注意点：
1、不要和实现范式对抗，我们总是可以用别的方式来考虑领域，找到适合于范式的模型概念。
2、把通用语言作为交流的基础，坚持用Ubiquitous Language讨论不同模型，有助于消除多种建模范式间的鸿沟。
3、不要一味依赖UML，UML确实有一些特性很适合表达约束，但并不是在所有情况下都适用，有时候其它风格的图形（可能适用于其它范式）或者简单的语言描述比牵强地使用某种对象视图表达力更强。
4、保持怀疑态度，不要滥用混合范式，要问下自己是不是不得不用混合范式，在使用混合范式前，确保各种可能性都已经尝试过了。如果可以，还是使用统一的对象建模更能保持模型的统一性，哪怕稍微显得不是那么优雅。
如果能够用一种范式解决问题是最好的，在判定一种范式无法解决当前的设计问题时，一定要反复确认不能盲目决定。

四、总结

所有的设计都是从基础开始，一个设计的优劣，往往决定着最后实际实现的结果。不同于现实世界的建筑或者机器设备的设计稳定性，软件的设计往往伴随着的是巨大的最终不可确定性。这也是网上漫画里设计师要求人们发誓不再修改设计的笑话。所以，MDD中，最主要就是要把模型设计的优秀。耦合度的降低，就代表着在扩展时，不容易遇到无法修改或者修改的代价太大的问题。所以掌握好基本的模型设计纲要，从底层把模型设计的思想融会贯通，才是领域设计的第一步。
万丈高楼平地起，打好地基很重要。