DDD的Service用DCI的替代方式

11-05-12 liontseng
Banq大哥认为用场景可以代替DDD的Service,我认为也是的;同时,我也认为角色的交互方法可以。
由于Service是静态的,也由于历史原因,我们现在要把Service挖出来,变成两种方式来表达。当然我们既然要代替DDD Service必然不能认为这个就是那个的“变身”,因为是突破性的,也就是变革性的,所以无法一一对应。

那么,我们现在抛弃DDD Service概念,回归到场景和角色的交互方法上来看待。

场景和场景之间完全可以沟通,场景在实际运作中,也可以把另一个场景当作一个“Service”看待,好比镜头切换,比如一段“回忆”,而这个回忆是为当前场景做铺垫的一样,但是这个和传统的Service不同,场景更加的丰富和智能,扩展和伸缩性更好。

另一方面,角色的交互方法可以调用另一个场景,这样另一个场景也变成了一种“服务”的概念了。

一下是题外话而已:
其实,有时候我们可以把角色具有的Function分解出来,比如:


function a(){}
function b(){} 
...

function RoleA(){

}

RoleA.prototype.a = a;// 这样写可以重用,题外话啦。
RoleA.prototype.b = b; 

function RoleB(){}

RoleB.prototype.a = a;// 这样写可以重用,题外话啦。
....

<p class="indent">

[该贴被liontseng于2011-05-12 15:59修改过]

banq
2011-05-12 16:34
嗯,原来我是担心如果服务被角色行为替代,会引发角色行为绑定,看了你代码两者可分拆重用的,不错。
场景有一种容器或面的感觉,而角色是面上的一个点,角色和行为发生结合的地方我们也能称为场景,所以,场景这东西很微妙,属于阴阳中的阴,不会单独存在,而是伴随角色行为出现的,所以不容易把握,当然有时业务上场景会很阳,驱使我们去呼唤角色实施行为。
场景替代服务,会对SOA进行冲击和提升。

liontseng
2011-05-12 17:27
DCI相对DDD来说,灵活度提高了;这样释放出了原始的阴阳之气,可以产生万象万物。有时候确实不应该局限于Java的固定类/对象/方法的概念局限,否则就成了“道可道就是道”了。
Javascript我喜欢用它举例,感觉他的概念都在混沌之间,无形大于有形,方法也可以是对象,对象也可以是数据 ...... 万物变换转换无极 ,大道至简至易。

SpeedVan
2011-05-13 10:09
以类实现对象,只是一种方式,而我们的确看到类的局限性。只因类实现的边界比较静态。方法(函数)对象化是类语言的趋势。一旦行为可装配,则会带来一系列动态。而DCI范式也就更容易,优雅地实现。

至于对象这一概念,它代表的是边界,即使用Javascript也一样存在。

banq
2011-05-13 11:15
2011年05月12日 16:34 "@banq"的内容
场景有一种容器或面的感觉,而角色是面上的一个点,角色和行为发生结合的地方我们也能称为场景,所以,场景这东西很微妙,属于阴阳中的阴,不会单独存在,而是伴随角色行为出现的 ...


刚才看了DCI的wiki解释:其中有:
In summary, a Context comprises use cases and algorithms in which data objects are used through specific Roles.

容器确实是一个容器,是一种包括comprises,它是一种用例,如果熟悉UML用例图,那么Context对应用例图中的scenario;而四色原型其实也是用例图的另外一种表达方式,用四种颜色来分解用例图,所以,无疑四色和DCI都是来源用例,他们两个之间是可以找到映射关系的。

所以,虽然DCI中没有角色出现,其实I行为已经隐含是角色行为,正如用例图中功能行为一样,基本是角色的行为,如图:



liontseng
2011-05-13 11:40
感觉上来说,Context对象应该有一个运行run() 的方法,然后内部是由各种角色IM交互的过程。而角色那个调用哪个是由剧本的这个场景Context对象安排的。而实现这个IM的内部是由于一个地基的,那就是DDD的领域部分,是相对固定的。具体说明代码可能如下,请各位一起脑力激荡。

下面实现以下Banq的这个用例的说明代码,不一定对,大家一起讨论吧
以下代码是说明性代码,只是说明个意思而已。

function 销售场景(销售员角色){
    this.销售员角色 = 销售员角色;
}
销售场景.prototype.interact = function(){
    this.销售员角色.扫描商品();
    this.销售员角色.计算价格();
    this.销售员角色.实现支付(); // 这样写不合适,只是说明个过程
}

<p class="indent">


调用代码->

var 销售员角色 = new 销售员角色();
var 销售场景 = new 销售场景(销售员角色);
销售场景.run()
<p class="indent">

showerxp
2011-05-27 21:38
2011年05月13日 11:15 "@banq"的内容
那么Context对应用例图中的scenario ...

一般定义上理解,用例中的scenario——场景,指的就是那些(场景)步骤的集合,比如成功场景、失败场景、备选场景什么的。而描述用例之间某种联系的用例图是看不出场景的。抛开用例,也就是抛开用例场景来看用例图没有太多意义,因为在陌生领域中,光看这些图还是不能捕获需求。而单个用例具有单个完整的业务处理流程,有开始,有中间处理,有完整的结果。所以,单个用例是有其意义的,单个用例图而不能获得其中那些用例的详细信息就意义不大。就上面这张用例图来看,我们知道销售员是用例“扫描商品”、“计算价格”、“实现支付”的参与者。至于怎样扫描、计算、支付就一概不知。

以上内容与本主题无关。

猜你喜欢