这是partech的blog的内容，我想我对这个问题应该算是小有研究，拿出来供大家参考。

首先要说明的是PartyRole和Party到底都是什么？PartyRole，简而言之，就是角色（可能是人的角色，也可能是物的角色。人的角色如：父亲，儿子，丈夫，员工，物的角色如：抵押品，车辆，固定资产。。。）。 在早期的OOAD中（特别是使用了传统的名词概念法），这些都是显而易见的领域对象。而且，在大多数人的印象中，这些确实也被做为领域类（和实体类）存在的。

这样做的隐含的问题就是：软件描述的环境跟实际的业务环境不符，为什么这么说呢：举一共简单的例子：我是我老爹的儿子，我是我儿子的老爹，我是我老婆的老公，我是cheeloo soft公司的员工，在同一时段，我（这个人）居然拥有了4个角色，这也就意味着，我要在系统中填写4遍个人信息（或者，让系统管理员替我填写，累死他，哈哈。).

于是，精通OO的人们，进行了细粒度的划分，抽取出来一共存储特定人员信息的人员实体，该实体与人员的职务或角色无关，比这个被抽出来的"人员 Person"，更抽象的就是Party。Party是（person 和organization的深层抽象).

信息的冗余带来的坏处，我就不多说了，反正在过去，上的都是部门级的系统(如财务/销售系统)，而现在的趋势是上企业级的系统（如协同)，这就给我们的软件提出要求：集成和整合冗余数据。

我经历过的几个系统，都提出过类似的要求：比方说YCV3系统，提出：国家要求政企分开，专卖局和商业销售公司是一套班子，两套组织机构，有不同的权力范围和汇报关系；比方说：顺德某银行，要求其系统：任意找出两个节点，系统计算出它们之间的关系（如，张三是本银行的雇员，并且在某年某月某日，替自己的亲戚做了个房产抵押担保).

因此，Party和Party Role，在领域概念中，是两个不同的实体。是不是要把这两个领域类区分出来，取决于你的业务环境，比方说，你要开发的是一个企业级系统，有着明显的业务意图，把Party从Role中分离出来，那么，不把Party分离出来，就会造成后期的需求变更（变更不可怕，关键是变更带来的严重后果)；如果你开发的是一个简单的系统，比方说在线考试系统，基本上，不会有客户对你说："小X，我想看一下，我们的监考老师和考生是不是一个人？"，那么你就没有必要把PartyRole和Party分开。

说到在线考试系统，我想简单提一下，在ColorUML中，有两种不同的颜色来区分Party和PartyRole，Party是绿色，PartyRole是黄色。比方说考生，监考老师，就是黄色。。。

当然，我们也必须看到，Party和PartyRole的分离，增加了模型应对变化的弹性，但会带来一系列的实现问题：工作量增大，理解难度加深。

我们讨论的是领域层面的概念，其实，在数据库实现中，还是有多方法来体现这个领域模型的：
方法1： sap bizOne系统中，Party和Role是一张表，增加一个角色，就把原来的人员信息copy一份，只是在role那个字段上，有不同的值，系统维护数据冗余。
方法2： bsp，严格按照领域模型实现，后来加入缓存和冗余字段来提供性能。
方法3：大多数系统 ，单独的表，记录和记录之间有关联，业务逻辑采用hard code。

作为一个扩展，我想说：很多系统中，会把用户和员工放到一个表中，其实，这样的系统应对变化的能力会非常差。比方说，现在，企业要上portal，员工、领导（有点特权的样子，挺QP，呵呵）、供应商、零售商需要用不同的门户登录。那么，用户的密码（或者是其他的登录凭据）会分散到几个表中，这给统一登录带来了不少的麻烦。更有甚者，一个人，在不同的单位挂职，要求登录后，看到其能力范围内的权限菜单。这时候，User就不是跟Party相关，而是跟PartyRelation相关了。

因此，Party ，PartyRole，PartyRelation，User是不同的领域类。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=752750