缘起：
Partech的blog以及与"在别处"的讨论。
Classification pk Generalization：
让我们回到旧的历史场景，蒙古人打进北京，建立元大都，汉族人对元政权嗤之以鼻，称其为"鞑子"；若干年后，满族人入关，定都北京，汉族人仍然不服，嚷着"反清复明"。关于这个历史场景，《中国哲学简史》上有着精彩的点评：""
因此，当时的某一个人，因为对其的评价角度不同，使得他产生了裂变。我们用UML图表现出来，大约应该是这个样子。
图1 不同的角度看待同一事物，即对事物的多重分类 (Multiple Classification).
注：在UML2.0中，称泛化箭头旁边的"文化"和"种族"，为泛化集(Generalization Set)。
分类指定一个对象和它的类型之间的关系（Classification refers to the relationship between an object and its type.）
这跟我们原来想像的继承关系有很大的差距，在大多数人的印象中，继承就应该是单支的，也就是说，一个对象最后终会属于一个类，现在出现的多重分类，破坏了大家的这种印象。很多人因次，放弃了这种方案的实现。
面对这个分析模型，我们真的要放弃吗？答案当然是否定的。
我们来看问题的本质：对给定的一个Person 类的实现，怎么让他同时具有华夏和蒙古族两种分类？我们需要转换思路，把图1中，所有的Class都看成是Interface，然后，写一个新的类，来实现所有的这些接口。
图2 一个真正的对象，实现并对外暴露了众多的接口，封装了复杂的内部逻辑。
这非常类似于com对象的实现。（感兴趣的朋友，可以查看COM规范中的IUnknown 接口之 QueryInterface方式的实现要求）
ThingType vs. Thing
在与需求人员交流后，我们又被告知，对一个人，需要添加新的分类标准：收入类别。按照一个人的月收入情况，可以分为 "1000以下"，"1000－3000"，"3001－6000"。。。
因此，最终用户实际想看到的分类结果，可能是这个样子：
| 标识 | 名称 | 分类 |
| 0001 | PersonA | 文化：华夏 种族：满族 收入：1000－3000 |
| 0002 | PersonB | 文化：狄夷 |
| 0003 | PersonC |
|
表格1 ： Type的实例
从上面的表中，我们可以看出：
1 一个人可能存在多种分类，也可能一个也。003没有任何分类，这是允许的，只不过是在统计的时候，可能会与某些人期望的不相符。
2 我们用这些分类，基本上是用来做统计用，很少去关心："如果你是一个狄夷，那么我们就会。。。。"。因此，我们可以将Type压缩（扁化）,只是简单记录之间的分类结果就行。
根据上面的数据，那么我们可以建立自己的数据模型：
图3 数据模型的"分类"实体和"Type"实体。
值得注意的是，在PersonType表中，存放了所有的分类类型（不管是"文化"的，"种族"的，还是"收入类别"的。。。）
其实，在领域模型中，是否要出现对应于数据模型中的Type，有过很多的争论。要知道领域模型知识级别中的Type 和数据模型中的Type，是两个不尽相同的概念。
图4 领域模型的PartyType
从理论上，我们很少在领域模型中看到对应数据模型的那个Type的出现。在领域模型中如果出现了Type，那么基本上就是建模者想让模型的约束力更强一些。也就是说：在领域模型中的Type，要么跟Rule相关，要么跟某些行为相关，更关注的是一种对操作层对象的装配和动态控制能力。我们从图4中，也可以看出。Party和PartyType是对多1的关系。而在数据模型中，Person实体和PersonType实体是多对多的关系，因此，出现了PersonClassification实体。
分离PartyRole：
一个Person，在实际的业务环境中，可能会扮演多种角色(Role).Role其实是众多分类法中的一种分类而已，我们可以很容易的加上一种新的GeneralizationSet（或者多种）,换句话说，Role是众多分类中的一个子集,因此，它也可能是多重分类(multiple classification)。不过，因为业务的需要，更加关注挖掘Role的附加信息而已。比方说，我们要关心在逃人员这类控制对象，我们要了解，该人员是什么时间被通缉的，所犯何事。这类信息，就是该角色特有的信息，因此，根据Peter Coad的《Color UML》中的建议，我们会把Role当成领域类来处理。
图5 增加了"控制对象"泛化集，按Role进行分类。
把Role领域对象提取出来，不能简单的了事。作为一个DDD的实践者，我们更希望把模型和实现相绑定，刚才扁平的Type实体的解决方案，就无法满足我们的要求了。我们还有以下的选择：
l 把各种Role分开成单独的类，都继承于Party。因为各种角色之间存在组合或者互斥的关系，我们就很难确定这些角色的扮演者是不是一个人，即使是把Role的对象彼此关联起来，那么还有数据冗余的要处理的难题。此外，还有，就是这个模型如果发生了改变（比方说增加了一个新的要关注Role，或者一个Role转变成另一个Role时），这个模型的实现逻辑就要改变。
l 把PartyRole变成一个抽象类，下面有若干的子类。(如图6)。需要注意的是，PartyRole的子类仍然存在组合或者互斥关系（比如 "客户"和"供应商"都既可能是组织角色，也可能是人员角色，而组织角色和人员角色之间是互斥的），不过要想在这个模型上加以限制，就比较容易了。同时，这个模型对动态分类的适应能力也比上面的那个方案强一些（其代价就是，模型比上面的模型复杂了些）.
图6 分离出来的PartyRole。
如果想继续探讨PartyRole，我们就会发现：
l 有独立于关系的角色，也有依赖于关系（Relationship）的角色。独立于关系的角色，如：医生，公证员。依赖于关系的角色，如：雇员、学生。对于依赖于关系的Role，如果我们要记录其关系相关信息，那么就要把关系单独抽取出来（e.g .公司的某个客户，有3个销售人员与其有业务往来。A销售员跟这个客户特铁，因此，这个客户对A来说，是金牌客户；但是对C销售员来说，这个客户只能算是一般客户。"金牌"和"一般" 是针对关系而言的，不能放到Role中）。
l 有事务相关的角色，也有通用的角色。事务相关的角色，如：某个文档的作者，某次存款业务中的储户，某笔订单中的付款人。通用的角色，如：医生、客户等。。。。我们常把事务相关的角色，在数据权限（和业务逻辑）中处理。
Role和Relationship的表示法。
那么，我们在建领域模型的时候，应该怎么表示Role和RelationShip呢？有两种方案：
1 简化的做法：
图7 学生和老师 （用黄色表示是Role）
2 较为抽象的做法：
图8 Person的自关联，在两端写角色 ，并注明关联的名称。
数据模型的实体定义：
下面是在数据模型中的实体概念定义,会帮助我们把数据模型和领域模型串起来，虽然其中还有些许差别。
l The PARTY entity defines the nature of the party,which will not change over time.
l The PARTY TYPE classifies the party into certain categories.
l The PARTY ROLE entity defines how a party acts or, in other words,what roles the party plays in the context of the enterprise's environments.
l The PARTY RELATIONSHIP entity allows parties to be related to other parties and maintains the respective roles in the relationship.The PARTY RELATIONSHIP entity has attributes of from date and thru date in order to show when the relationship started and optionally when(and if) it ended.
参考资料：
UML Distilled 3ed
The Data Model Resource Book
Domain-Driven Design.
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=752759
