领域对象与业务逻辑关系设计思路

11-01-05 cuwkuhaihong
前一段时间我用面向的对象的方式来写我自己的一个小JEE应用程序,业务逻辑比较简单,就是一些“增删改查”的工作,我一直想把我的小应用程序纳入实际应用中,后来在JDON上看到了大家关于DDD的困惑,我也遇到了业务逻辑该写在什么地方。

经过一番思考之后,我设计出了一个新的编程方式,我认为已经从理论上解决这个问题,所以在这里与大家分享一下。如图:


我的每一个Model都是由“对象”+“上下文”(一个*.properties配置文件,也可没有),model可以完成自己的“增删改查”,Model也可以说是“领域对象”,包含属性和行为,在没有什么业务逻辑的时候,即只有“增删改查”,也就没有必要写service类了。只有当model(领域对象)的某行为包含业务逻辑的时候,才写包含业务逻辑的Service,然后让这个model在调用service完成,时常调用者会把自己作为一个参数传入,意味着自己参与了逻辑。无论逻辑上怎么变化,view与后台交互始终未变,因为view调用的是model的方法。

在说说业务逻辑,其包含:制度,规则,算法。领域对象应该是参与在制度和规则之中,只有算法可以认为是工具。所以我才说Model调用service的时候,如果service是制度和规则描述体,就应该把领域对象自己传入其中。想想你去银行办一张卡,你,柜员,电脑,银行都是交易规则和银行制度的参与者。

                   

5
banq
2011-01-05 10:15
你这个想法很好,你将业务逻辑的行为放入Service中,比如你去银行办一张卡,你,柜员,电脑,银行都是交易规则和银行制度的参与者。

这实际上代表了面向函数语言派的一种观点,一个交易动作中涉及到多个实体,我们是不能将交易动作封装到实体模型中,那是不是放入服务中呢?

初步来看,是可以的,如果业务行为比较多,我们就建立粗粒度的大服务,这就是SOA中讲的服务,那么我们的架构就成为以服务为切入点的SOA系统。

所谓一山不容二虎,就象当初数据库和对象两种到底谁为第一一样,因为在实际操作执行中,必须明确先主后次,才有可操作性。关于方向战略的选择上,从来没有两个并列,就象东南西北,你只能选择一个方向。

如果复杂系统中,我们以SOA的服务组件为主,那么无疑我们的领域模型就居于其下,那么我们用什么统一语言和业务专家沟通?

SOA是想让业务专家学会SOA语言,所以,你看到很多软件公司销售员嘴上都是SOA了;而这种将技术架构普及给不懂计算机的业务专家做法,曾经在数据库时代失败过,他们也曾经想把数据库概念让不懂计算机的业务专家去接受。

在我最近写的DDD的PPT中其实已经回答这个问题。答案就在DCI架构。

所以,DCI能够消灭MVC,也能会和SOA进行竞争,当然,你可以把SOA的服务帽子套在DCI上(见这个案例),但是时间久了,人们就要问:还要这顶服务的帽子干什么呢?

jdon007
2011-01-05 10:29
有两个很明显的地方,觉得有待商榷:

1)每个model都可以完成“自己”的增删改查?

2)界面只与model打交道?

我的观点如下:

1)如果这个model是个“元素”级别的实体,那么“元素”自身,可以增删改查吗?

举个简单的例子,比如一篇博文(blog),博文没有“生命”或者说并没有“自主行为”,博文的“增删改查”操作,也许放在“博主”(blogger)这个模型中更合适,也更符合常识。

那么博文本身就是简单的数据容器吗?比如,博文本身的格式化与反格式化(解析)的方法(可能会调用一些格式化工具)可以放在博文这个实体之中,这样业务场景或博主调用时,很容易想到。

也就是说,尽管博文本身是没有生命的,但出于方便(而非逻辑),也可以将一些方法放在博文中。

2)如果这个model是个“集合”级别的实体,那么“集合”是可以对其元素进行“增删改查”的。但是领域中总有一个(些)“顶级集合”(容器),其“增删改查”可能要放在service中。

除了这些顶级“集合”的“增删改查”操作,可能要放在service中。一些元素的“增删改查”操作也可以出现在service中。

比如,一些业务场景也许要“查”博文(推荐、搜索等),那么这个“查”就无需去调用“博主”的“查”博文的方法了。

对这两点稍微归纳一下:“增删改查”操作,一些“只”出现在model中(大部分元素级别的实体),一些“只”出现在service中(顶级集合级别的实体),一些则可能同时出现在model和service中(一部分元素级别的实体)。

但“增删改查”无论出现在哪里,都为领域语言所封装,界面不直接看到这些操作,看到的是领域语言所描述的操作,而非数据库语言所描述操作。此外,service可能包含一些复杂的交互,如业务规则、算法等。

就我个人而言,我将“赠删改查”理解为“领域模型或服务”的“数据”的记忆机制,不过目前好像缺少了对“行为”的记忆机制,这也许需要引入动态语言机制。

3)model与service我看作是领域的两个方面,前者包含一个实体自己就可以完成的事情,后者包含诸多实体相互协作方能完成的事情。界面都可以直接使用它们。目前,我一般命名为domain和service,这个和你的model与service应该是相同的划分。

一个实体可以完成的事情相对固定,而诸多实体相互协作可以完成的事情就很多且有良好的扩展性(或者说符合开闭原则)。这也是“领域模型”(实体)相对“领域服务”(服务、场景)相对稳定一些的原因之一吧。

我觉得模型(实体)与服务(场景)是对领域的一种划分,模型关注领域的个体行为,场景关注领域的群体行为,模型关注领域的静态结构,场景关注领域的动态功能。这也符合了现实中出现的各种现象,有动有静,有独立有协作。这样理解,也许更符合常识,也就是说将需要学习和领悟的时间降低到最少。

cgttian
2011-01-05 23:12
2011年01月05日 10:29 "jdon007"的内容
模型(实体)与服务(场景)是对领域的一种划分,模型关注领域的个体行为,场景关注领域的群体行为,模型关注领域的静态结构,场景关注领域的动态功能。 ...

cuwkuhaihong
2011-01-06 09:17
jdon007

你可以看一下,我的这一篇blog领域对象设计

这篇文章讨论了,你提的问题。

[该贴被cuwkuhaihong于2011-01-06 12:26修改过]

猜你喜欢
5Go 1 2 3 4 ... 5 下一页