使用JF可以轻松实现DCI架构。事件的生产者实际是DCI中的角色，JF运行时通过将角色注入到模型中实现其角色扮演功能。

DCI:数据Data, 场景Context, 交互Interactions是由MVC发明者Trygve Reenskaug发明的。 见 DCI架构是什么？ DCI让我们的核心模型更加简单，只有数据和基本行为。业务逻辑等交互行为在角色模型中 在运行时的场景，将角色的交互行为注射到数据中。

JdonFramework的Domain Events是DCI的交互行为，在实现领域事件的同时也实现了DCI。为更清楚说明DCI，下面以JdonFramework案例说明。源码见： SimpleJdonFrameworkTest.rar

领域模型是DCI的Data，只有数据和基本行为，更简单，但注意不是只有setter/getter的贫血模型。如下：

@Model
public class User Model {

     private String userId;
     private String name;

     @Inject
     private ComputerRole computerRole;

<p>

Domain Events事件或消息的生产者也就是DCI中的角色Role，比如我们有一个专门进行计数计算的角色，实际上真正计算核心因为要使用关系数据库等底层技术架构，并不真正在此实现，而是依托消息消费者@Consumer实现，那么消息生产者可以看出是一个接口，消费者看成是接口的实现：

@Introduce("message")
public class ComputerRole {

     @Send("computeCount")
     public DomainMessage computeCount(User[author]Model[/author] user) {
          return new DomainMessage(user);
     }

     @Send("saveUser")
     public DomainMessage save(User[author]Model[/author] user) {
          return new DomainMessage(user);
     }

}
<p>

DCI第三个元素是场景上下文Context，在这个场景下，ComputeRole将被注入到模型UserModel中，实现计数计算的业务功能：

public class ComputeContext {

    private DomainMessage ageAsyncResult;

     public void preloadData(User[author]Model[/author] user) {
          if (ageAsyncResult == null)
               ageAsyncResult = user.getUserDomainEvents().computeCount(user);
     }

     public int loadCountNow(User[author]Model[/author] user) {
          preloadData(user);
          return (Integer) ageAsyncResult.getEventResult();
     }

     public int loadCountByAsync(User[author]Model[/author] user) {
          if (ageAsyncResult == null)
               ageAsyncResult = user.getUserDomainEvents().computeCount(user);
          else if (ageAsyncResult != null)
               return (Integer) ageAsyncResult.getEventResult();
          return -1;

     }
}
<p>

DCI应用源码下载：SimpleJdonFrameworkTest.rar

开发文档：JdonFramework模型驱动快速开发

更多文档：http://www.jdon.com/jdonframework/manual.htm

关于领域事件和DCI纠结讨论见：

DCI,领域模型，领域事件的一些想法，该文讨论场景和事件到底应该如何结合？怎么结合？

DCI并不反对继承 一文认为DCI目前最大的不确定性或者说问题是何时以及如何定义一个Context上下文场景？我个人认为通过领域事件实际上巧妙回避了这个问题，因为事件隐含了场景。

[该贴被banq于2011-09-10 17:09修改过]

[该贴被banq于2011-09-13 12:14修改过]

感谢banq的不懈努力。

  对于DCI，banq的提供思路在大多数场景下没问题。不过在我遇到的实际应用发现，在更复杂的场景中，领域对象的事件响应可能还会因场景不同而不同。这也就是说，大多数情况下主要由场景触发不同的领域对象事件，但领域对象的事件响应还可能进一步细分为不同的场景。

  所以领域对象事件和场景可能是相互交织的。不知道banq有没有更好的思路。

不知道jdon还记得我不，很久以前发你一个邮件，现在我也在java的领域中遨游了！最近的几篇主题LMAX和disrutor,让我非常刚兴趣。貌似我在多线程并发领域总是很有兴趣。

废话不多说。我看了disruptor的主题文章，如果真如文章所说，这个是目前最快的并非处理，那么在我一直在想，这个技术是否可以用到我们公司的系统中去。因为我们公司目前的系统虽然完整，但是咋性能上没有下很多时间，因为需要追求稳定。（插播下广告：我在职的公司是深圳的安捷信联，深圳的手机深圳通就是我们的产品）。而我们公司的系统驱动就是使用open mq的队列消息。我对disruptor的唯一担心是，他稳定吗？可以在并发情况下，保证数据的完整性等一系列问题（问题提的不好，见谅！）。

希望可以有更多的相关的文章，我很希望能够学习下这个技术。

目前我也比较纠结..这个问题需要详细讨论才可能有好的思路，如果说场景或上下文是一个“面”，那么事件是“面”里那个点。场景在技术还要实现混合Assigned注入等作用。

这个问题Martin Fowler的LMAX架构已经回答了，LMAX团队在2010的Qcon大会汇报了他们这个技术，直至2011年老马写这篇文章，至少已经已经稳定运行一年，LMAX他们有专门的博客http://blogs.lmax.com/。