关闭

[领域]当Party就是PartyRole会这样

标签: 领域模型usersap数据库blog扩展
1721人阅读 评论(1) 收藏 举报
分类:

这是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是不同的领域类。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:187062次
    • 积分:2930
    • 等级:
    • 排名:第12447名
    • 原创:76篇
    • 转载:0篇
    • 译文:0篇
    • 评论:146条
    最新评论
    RHG中文翻译团队