DDD的Service用DCI的替代方式

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;// 这样写可以重用，题外话啦。
....


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

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

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

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

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

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行为已经隐含是角色行为，正如用例图中功能行为一样，基本是角色的行为，如图：



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

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


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

调用代码->


var 销售员角色 = new 销售员角色();
var 销售场景 = new 销售场景(销售员角色);
销售场景.run()

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

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

以上内容与本主题无关。