场景Context是新的对象类型

Contexts are the new objects一文提出DCI架构中Context是一种新的对象，不同于我们现在的对象语法。

当我们从过程化编程转移到面向对象编程时，我们把输入参数id作为对象的指针，如下：

面向过程写法：注意id作为输入参数
procedure(id,param1,param2)

面向对象写法：id被隐含，实际作为对象的标识了。
object<id>.method(param1,param2)

实现DCI一般是在无态服务中，服务提供了DCI实现的场景，那么语法就如下编写：
service.method(id1,id2,id3,param1,param2)

按照前面面向过程到面向对象的转换规律，我们可以将场景实现更简单更OO：
context<id1,id2,id3>.interaction(param1,param2)

id1 id2 id3隐含在context中，说明一个场景是由三个方面因素决定的，是动态的。

这样我们再也不必一个个先寻找构成context的对象，确保他们OK正常，确认他们之间关系等等，所有这些都在Context 构造中实现(正如一个对象初始化构造一样), 这样，我们就可以关注如何使用Context，而不必关注如何构造(工厂模式思想延伸)，我们可以关注场景的行为了.

作者认为场景对象会替代无态服务。

http://www.artima.com/forums/flat.jsp?forum=270&thread=287546&start=0&msRange=15

个人观点：
我之前提到两种实现方式：
Domain Events：服务是事件的入口，外部事件进入服务后，被服务传递给领域模型，由领域模型驱动相关服务或仓储或相关算法完成一定职责行为。

Context对象：专门设立一个场景Context对象，服务-->场景，在场景中注射服务或仓储或算法，完成相关场景的职责行为。

看来没有必要再服务-->场景了，直接使用场景替代服务即可，否则多个环节干嘛，也可以使用场景替代MVC中Controller，更加简化。

[该贴被banq于2010-04-06 17:39修改过]

2010年04月07日 14:30 "Antinomy"的内容
InfoQ刚好有篇介绍上下文的 基于上下文图的策略性领域驱动开发 ...

这篇主要用来进行分析需求中的上下文，试图采取分而歼之老策略：
>应用程序中正存在着两个不同的上下文。“歧义”是通用语言的头号大>>敌，我们必须铲除它。

其实很多时候，是无法分离和铲除的，上下文场景不同，同一个实体扮演的角色是不一样的，DCI是正视这种现实，不回避。


>这意味着我们要使用不同的模型。但是两个模型又可能有非常紧密的交互。

看来他采取的策略是不高明的，怎么能因为上下文不同就建立两个不同模型呢，按照DCI，实际是同一个模型在不同场景的角色不同，所谓“交互”应该是Context场景的交互。

DDD中我好像没有看到这种静止的模型处理方法，应该是该文作者自己的心的。

当然，我们在分析需求时，通过识别出场景，划定上下文边界，也是最重要的，否则你的用例图都无法准确表达出来。在这个方面是有积极意义的。

既然上下文也就是场景如此重要，我们在进一步细节设计时，就不应该使用该文推荐的两个静止模型代表两个上下文场景的实体，如果有三个更多上下文呢？如何保证方便拓展呢？

任何思想都有角度，有角度就有偏差，所以，在学习和演习发展DDD时，一定要注意DDD思想本身的静止性，忽视对象职责这个动态性的偏差。


2010年04月06日 16:51 "banq"的内容
看来没有必要再服务-->场景了，直接使用场景替代服务即可，否则多个环节干嘛，也可以使用场景替代MVC中Controller，更加简化。 ...

用场景对象替换Controller这个想法我和oojdon去尝试下。如果将controller作为场景的话，那么框架就需要保证场景对象的不变量约束，这里有一个问题，业务层的IOC容器使得无状态的技术组件之间的依赖和不变量得到了满足，jdon的DDD支持，使得模型对象的不变量得到满足，那么场景对象的不变量约束应该有表现层框架支持还是业务层框架支持呢？

2010年04月08日 11:52 "xmuzyu"的内容
那么场景对象的不变量约束应该有表现层框架支持还是业务层框架支持呢？ ...

可能要颠覆传统的分层架构，很有挑战性的难题，如果我们用场景替代MVC的控制器或服务，那么整个应该就是一个纯Web架构，RoR实际也就是这样。

View --> Context ---> Domain Model ---> Component/Respository

就搞这几个层即可？

2010年04月08日 14:19 "banq"的内容
View --> Context ---> Domain Model ---> Component/Respository ...

个人感觉上场景Context应该是和View绑定的，比如说起“登陆”场景一般会想起某个页面上有用户id和密码的输入框，“借书”场景首先会先想起图书馆之类的。场景之间是类似地图一样，从某个根入口出发，进行场景的转换。
另外一件很有意思的事情，就是我发现这个概念跟开心网的网页游戏武林风云里的场景的概念很接近，
例图如该游戏主城的一个场景地图：该场景有城门作为根入口，每个场景都有特定的npc，触发特定的任务和服务。



[该贴被Antinomy于2010-04-09 09:43修改过]

是的，直接通过场景和试图绑定，比MVC模式中的Control要自然得多，MVC模式其实是一个结构性模式，因此不适合互动行为能力很强的应用，比如Web 2.0 社会媒体或游戏等，简单的企业应用是可以的。

所以，可以认为DCI架构颠覆了MVC模式，宣告MVC模式已死，见下图：

场景其实将MVC中Control和模型挖出来，进行了组合。这是一种与MVC模式考虑角度完全不一样的新角度，这种角度更符合OO。

其实MVC的控制器有很多缺点(见对象设计：角色、责任和协作"(Object Design: Roles, Responsibilities, and Collaborations))：
1.Control logic can get overly complex. 控制器会变得复杂，很多人在Struts的Action控制器中写业务代码已经变得很常见，所有的操作都在action中，有的action都几乎上千行了

2.Controllers can become dependent on information holders' contents.控制器变得依赖信息数据中心或数据库了，控制器做很多事情，意味着领域对象就做很少事情，控制器最后不是只会做什么，决定战略性的事情，也和怎么做，如何实现等战术问题耦合。

3.Objects can become coupled indirectly through the actions of their controller. 对象将间接地通过控制器的action耦合在一起，一个对象在控制器中查询获得，然后复制给另外一个对象，这两个对象就耦合在一起。

4.The only interesting work is done in the controller.唯一有趣的工作是做控制器，Responsibilities职责被吸进控制器对象，只将一些行为留给角色模型完成，重要的事情都集中在控制器中了。

从以上4个缺点可以看出，MVC模式实在罪大恶极。。。。。。。

用DCI替代MVC 用场景替代控制器应该是大势所趋。


[该贴被banq于2010-04-09 11:34修改过]

我的理解好像就是指的是总线吧，用总线的方式解决动态对象间的访问，MVP模式中有提到
但是用了总线之后就模糊了双方的主次也会有一定的负影响，不过在未被乱用的情况下的确可以做到低藕合
反之问题就可能变得更复杂

在Silverlight 中可以用到这种，以及在cs结构下实现一个事件总线也不是很难，但是要转之用到jsp或者asp/asp.net之上时，可能并不支持，因为每个jsp页面以及asp.net页面是无状态的，它们间的通信想要做到只能通过定时器去取static对象或者session才行


[该贴被bigmouthz于2010-04-09 13:28修改过]

进来学习的

看了最近jdon一些首页帖子,深深感受到这里学术风格,即使想发帖都要有所见解,而不是灌水.
看了如下图

越看越有意思.

context场景就是一杯鸡尾酒,不同场景需要制造不同鸡尾酒,原材料objects都放在context外,酿制过程即MVC中的流程全由场景处理.

本人还是才疏学浅,希望有天能融入jdon的讨论当中.