但同时要清醒地认识到，DCI是人对业务的主观认识，而事件才是真实的客观存在。不同场景之间可能存在着交叉或嵌套，就是同一场景也会充满着变化，容易出现对交互认识的遗漏或错误，这很难避免。这是一个客观规律，因为我们对事物的认识是需要过程的。    这需要在框架设计时，要考虑业务的柔性设计，可以很好的实现重构或组装。所以我希望“场景”最好是无形的，同时事件处理器的灵活和强壮。对于"事件处理器"，要能够处理领域内部事件、领域间的事件、基于事件的分布式计算，以及能够和ESB的良好整合。

“事件”常被我做成一个“钩子”，可以根据场景的变化或者考虑新场景而加入新的事件响应或者事件路由。所以场景不能太僵化而封装一部分事件路由，因为一个场景中的一部分事件路由可能同样出现在其他场景中。

[该贴被flyzb于2010-11-16 23:27修改过]

[该贴被flyzb于2010-11-16 23:34修改过]

[该贴被flyzb于2010-11-16 23:35修改过]

事实我们应该反过来想，那个整体是否由局部组成的呢？我们不可能一开始就扑捉一个完整具体的整体，即使在现实中，我们也是由局部开始的。客观抽象的整体可以说是不清楚的，我们是通过不断地对局部认识，然后慢慢组合成整体，于是我们就得到了具体整体。例如我们说到人，我们只能得到人这个抽象概念，可以说他是一个抽象整体，只有当我们认识了手，脚，头等，才可以组成一个具体的整体。可能有人会问，若果这个具体的整体跟客观的整体存在差异呢？那么我可能反问，既然我们只能得知具体的整体，而不能得知抽象整体是否如我们所想的那样，你咋能知道具体的整体跟抽象的整体不一样呢？或者说，人的认识永远是片面的，只有加入前提，才能成为全面的。

所以DCI角度上是基本没什么问题的，因为他符合人类的一种认识过程。而场景分割是否出现问题，是取决于对领域具体认识是否充分。DCI肯定会对客观整体的完整性和可扩展性造成破坏，这是不可避免的，这是由人的片面认识决定的。而对具体的整体的也会造成破坏，这是由认识的差异和是否充分等因数造成的。

对于“场景”无形，其实场景可以有形也可以无形，因为一个事件必定会引起有且只有一个场景（子场景可理解为再次分发事件），试想若果场景以事件来命名，那么有多少个事件就有多少个场景，这是有形的。但反过来，场景是没有名字的，只是一个载体，真正的行为选择取决于不是场景，而是事件，那么场景则是无形的。其实我们也可以从这里看出，DCI和事件驱动是殊途同归。

这个问题是这样看的，如果把DCI看成程序代码前端，那么事件是结果，事件是程序代码运行的一种结果，因为事件触发源泉来自于用户输入，事件带有能量的意思，可以把事件看成中医上经络或气。

既然事件是程序运行的一种结果，那么我们可能在分析设计阶段不必太考虑结果事情，更多的是关注业务场景，这个业务场景需要哪些角色参与，这些参与的角色的原始身份也就是实体是什么；参与这个场景中这个角色履行什么动作行为。

我的意思是这样：软件分析设计阶段更多是DCI，而只有到技术架构实现阶段才会考虑到事件，可能会通过组件方式来切割，组件和事件都应该属于技术架构层面的。

总的来说的确是这样，当人们不断地用DCI来分析设计时，慢慢地就会对框架产生需求，让代码更体现思维，让代码更可维护。在技术上的DCI，可以说是事件的封装。不知这样说是否合理呢