how to enhance Jdon framework to DCI framework ?

In Jdon framework 6.4 case , I use Domain Events implements a DCI:

Data Model of DCI:

@Model
public class User Model {
  private String userId;
  private String name;

  @Inject
  private ComputerRole computerRole;
}

Role : domain events is Role's interactions of DCI

@Introduce("message")
public class ComputerRole {

  @Send("computeCount")
  public DomainMessage computeCount(UserModel user) {
    return new DomainMessage(user);
    }

   @Send("saveUser")
  public DomainMessage save(UserModel user) {
      return new DomainMessage(user);
  }

}

Context of DCI: Role will be injected into data model:

public class ComputeContext {

private DomainMessage ageAsyncResult;

  public void preloadData(UserModel user) {
  if (ageAsyncResult == null)
    ageAsyncResult = user.getUserDomainEvents().computeCount(user);
  }

  public int loadCountNow(UserModel user) {
    preloadData(user);
    return (Integer) ageAsyncResult.getEventResult();
  }

  public int loadCountByAsync(UserModel user) {
    if (ageAsyncResult == null)
      ageAsyncResult = user.getUserDomainEvents().computeCount(user);
    else if (ageAsyncResult != null)
      return (Integer) ageAsyncResult.getEventResult();
    return -1;
   }
}

Domain Events and DCI are different perspective for one thing, DCI is from the UML(such as four-colors UML) map directly over the prototype , and therefore allows developers to deal directly with DCI that can reduce unnecessary translation of distortion.

So my idea is: Domain Events is as the underlying mechanism of DCI, from lower level to high: Dirsruptor ---> Domain Events ---> DCI, DCI is the highest level.

How about DCI and MVC? or DCI and Service of SOA? how to integrate them?

the Article :DCI patterns - how to write DCI context in Ruby have a problem: The most important part, however is the way the context class is written. Should the application object (a model) know about the contexts?
They say there are some options:

1. the application object has access to all the possible contexts. The controller just calls methods like: application.register_new_user(..) and it's the application that initializes the context.

2. controller has the knowledge about the specific "global" context it handles: NewUserContext.new(..).execute

3. controllers as we know them (Rails) disappear, the wiring between actions and context takes place in a configuration file.

I think REST + DCI is naturally pattern.

REST verb has four verb: post get post delete, these verbs fire events, the events consumer is the Restful resource, such as post a product, the "post" event will active url "/product". and in the class of "/product " will have a context that accept the "post" event. the context should be the context of DCI.

so in REST +DCI there is no MVC, MVC pattern is a structural pattern and not for events behavior pattern, but REST althought is for resource, but resource need operation events.

About REST's four verb 'post / put / get / delet' , the server can response to them in a resource manager context, the resource is same as data model of DCI, here is a post resource context:

@Path("/users")
@POST
public Represent post(UserModel user) {
    if (validate(user))
        return new Html("/newUser.jsp", "user", user);
    user.setUserId(Integer.toString(user.hashCode()));
    //assign DCI role to data model
    RepositoryManagerIF rm = (RepositoryManagerIF) roleAssigner.assign(user, new RepositoryManagerEventImp());
    //this method will send domain events to repository rm.remember(user);

return new State("/");
}

Robot source：GitHUB

REST + DCI + Domain Events example Robot download: here robot.rar is CQRS architecture.

DDD CQRS EventSourcing example source: football Match

CES:Context Event and State

JdonFramework DDD + CQRS + EventSourcing examples