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:


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

  private ComputerRole computerRole;

Role : domain events is Role's interactions of DCI


public class ComputerRole {

  public DomainMessage computeCount(UserModel user) {
    return new DomainMessage(user);

  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) {
    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:

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:


public Represent post(UserModel user) {
    if (validate(user))
        return new Html("/newUser.jsp", "user", user);
    //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