DCI 中场景的生命周期是如何的呢？

个人观点，DCI场景是和四色原型的MI对应，而MI是一种和时间有关的活动，那么无疑两者生命周期是一致的，某个活动MI结束，Context也结束。

当然，关注Context的生命周期之前，更重要的是关注场景的边界，当我们使用DCI这样业务需求和技术直接映射时，对象的生命周期已经是一种浑然天成的，因为我们的场景来自MI，而MI本身就是有生命周期的活动，所以，这就不必象过去我们使用OO语言那样，要特别关注生命周期，就象我们和某个人和物打交道，第一考虑的就不是他这个人活多长，或这个事物有多长寿命，而是直接关注我们和他或用它干什么。

这种革命性转变就象当初IOC依赖注入的自动配对@Autowired一样，Autowired让我们不必关注对象的创建，垃圾回收机制不必让我们关注对象的死亡，但是我们还要关注对象的生命周期，而四色+DCI可以让我们不必关注对象的生命周期了。

我敢预言，这必将是一场革命，老外们明白过来时，又要大呼小叫，然后我们更多国人才会屁颠颠乐此不疲。

生命周期，看似很高深技术，对于面向领域来说，它应该自然而然的东西。例如一件事发生了，于是相关对象生成，相关对象参与，完成后，回收的回收，回归的回归，这是自然而然的东西。

BANK新增了个新帖滚动文字提示的功能，不错，BANK是个有心人。
有个小问题，有些时候文字滚动会变得很快？/越来越快？

MI和Context不就是在说一件事？关于DCI的代码，论坛上也有，new Context(roleA,roleB).doSomething(strategyA);突出事件引发者new Context(creater).addB(roleB).doSomething(StrategyA);语言是一种描述而已，这是我自己的理解和写法，至于规范，还得等框架出来才会有。
[该贴被SpeedVan于2011-05-09 10:15修改过]

在附上Banq的写法:
第一步：根据用户创建一个阅读场景对象：
ReadContext readcontext = RootContext.create(userId)
第二步：由阅读场景对象来执行交互行为阅读：
readcontext.view(readed);
[该贴被SpeedVan于2011-05-09 10:20修改过]

生命周期也是场景的时间上的边界，这里边界是指空间功能上的边界，边界分时间和空间，如果我们采取方法帮助我们简化其中一种，不需考虑时间边界，着重空间边界，对软件分析设计无疑是有很大帮助。

请问各位，能否帮忙提供一下DCI的原始出处，多谢。。

请问各位，能否提供一下DCI的出处，多谢。。