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
|