接上，DDD更偏重于领域的静态结构，而DCI更偏重于领域的动态行为。两者不可偏废，而是相互补充和统一。
  对于DCI，我有一种担忧，一是角色漫天飞。如果场景类似，只是角色不同而已，有必要定义为不同场景吗？二是场景的复用问题。如果场景是无形的，那怎么复用场景呢？如果场景是有形的，那如何去防止场景的过多过滥呢？
  另外对于事件，那事件是由对象激发的，还是由场景激发的呢？
  对于以上问题，希望大家可以讨论。

这个很早就发现了，所以之前自己分析了下，一个特定的场景肯定发生相应特定的事件（MI），特定的事件决定了特定的执行者（Role）与他们特定的逻辑行为（Interaction）。个人认为MI的I与DCI的I有着大小边界的不同

UML Colors中特意分离出Role，个人认为其原因在于Role隐含着权限概念。也就是说某实体（DATA，PPT）能成为某Role就是一种验证过程。

没错，这正中场景的核心问题，不过个人觉得角色以粗粒度为妙。场景的话，要考虑相同德事件发生，你我都在买东西，这是一个场景还是两个场景呢？场景池，是否可以成为控制同时发生同样事件的件数呢？至于激发问题，本人较倾向场景，场景很有事件的味道。

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

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

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

ls DCI还是google一下吧，内容很丰富。

DCI原文中用到的是 context而不是场景吧？上下文于场景的最大区别在于“上下”既它是有承接关系的，在同一个场景中上下不同则面对的问题也会有变化，这个根本原因导致了角色在同一场景中的变化。在同一个房间里，面对母亲、妻子、孩子从根本上引起了我的身份转换：儿子－》丈夫－》父亲。

角色导致了行为和能力，这是DDD的范围；上下文变化导致了角色的转变，这是DCI的范围。DCI扩展和细化了DDD的思想，是有意义的补充和完整。

其实对于用例的直接转换，还有一个必须的东西要放到类里面。就是属性的约束。这个类存在依赖于属性的值在一个区间中。
解决这个问题的方法，就一个老法子，契约式编程。