开源JdonFramework 6.2全新发布

受Qi4j Baston和javAte等DDD框架鼓舞,JdonFramework 6.2全新登场,该版本进行了重大改进,将Domain Events作为重点架构引入,做到容易使用,架构可伸缩等特点,使Jdon框架向真正DDD框架又迈进一步。

当前DDD实践领域达成一个共识:领域模型应该和技术架构无关,至少是非常松耦合,那么领域模型如何指挥技术架构为其业务逻辑服务呢?

要做到这点,首先必须改变过去技术架构中的服务指挥领域模型的架构,虽然SOA架构已经成熟多年,但是容易误导很多人将业务逻辑写到服务中去,从而使领域模型空心化,也就是失血贫血了。

SOA的服务是一种粗粒度的、非常高度的、可能跨多个应用的服务,它不能包办某个领域模型自身的行为和方法,所以,当事件从SOA的服务传导到领域模型之中时,如果领域模型还需要再驱动技术架构为其工作,这套机制如何建立?向领域模型中直接注射技术架构的Repository或DAO会污染领域模型,让模型沾染技术架构的味道。

Domain Events – 救世主一文提出了一个思路,让领域模型发出领域事件,通过领域事件再驱动技术架构为之工作。

JdonFramework 6.2将Domain Events以异步消息机制实现,最大化实现了领域模型和技术架构的松耦合。技术架构图如下:

Domain Events的使用通过Annotation实现,非常方便:

JdonFramework 6.2全新PPT文档

下载开源JdonFramework 6.2

[该贴被banq于2009-11-03 09:30修改过]

如果加入异步和同步的事件处理策略就好了。

@Introduce("message")
public class MyModelEvent{

@Send("listenerName",asyc="true")
public ModelMessage xxx(){};


}

最后在MessageInterceptor中,根据asyc来判断是否要进行异步,不知道这样是否可行?

11月02日版本已经加入,缺省是asyc="true",如果希望同步就是显式声明
asyc="false"

哦,我去换个最新版本,我还是10月28日的6.2版本

支持一下。

支持,不过回复的人咋这么少?

2009年11月03日 09:30 "banq"的内容
受Qi4j Baston和javAte等DDD框架鼓舞,JdonFramework 6.2全新登场,该版本进行了重大改进,将Domain Events作为重点架构引入,做到容易使用,架构可伸缩等特点,使Jdon框架向真正DDD框架又迈进一步。

Qi4j,Bastion,JavAte,JF,学到了很多,谢谢banq
基于一个设计得非常棒的软件上做开发是多么刺激的事情。
[该贴被oojdon于2009-11-03 21:06修改过]

支持一下。

Jdon框架6.2由于在模型中引入异步消息,可以实现模型方法内部持久化操作,从而避免著名的Hibernate LazyInitializationExceptions问题,也可以避免使用Open Session in View (不得已的OSIV模式)。

ORM已经是过去的事情

另外可以在MessageListener处集成入JMS,JMS是可伸缩性并带有分布式事务方案,可以保证持久化等事务精确完成。


@Component(“JMSListener ”)
public class JMSListener implements MessageListener{
public void action(DomainMessage message) {
Connection connection = connectionFactory.createConnection();
Session session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
MessageProducer producer = session.createProducer(destination);
TextMessage message = session.createTextMessage(message.getSource);
producer.send(message);
}


[该贴被admin于2009-11-10 10:34修改过]

2009年11月10日 10:11 "banq"的内容
另外可以在MessageListener处集成入JMS,JMS是可伸缩性并带有分布式事务方案,可以保证持久化等事务精确完成。

@Component(“JMSListener ”)
public class JMSListener implements MessageListener{
public void action(DomainMessage message) {
Connection connection = connectionFactory.createConnection();
Session session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
MessageProducer producer = session.createProducer(destination);
TextMessage message = session.createTextMessage(message.getSource);
producer.send(message);
}


我在做DDD sample的jdon版,正准备准备这样实现

2009年11月10日 12:05 "oojdon"的内容

我在做DDD sample的jdon版,正准备准备这样实现

太好了,xmuzyu已经将Jdon框架的英文架构说明写出来了:
JdonFramework Architecture

相信Jdon框架在大家一起努力下,一定能走向世界(呵呵,用词有些过于豪放).

目前采用Jdon,其实也是采用了BASE策略,无论是BASE还是ACID都无法逃脱CAP的限制,ACID是为了保证较高的一致性而减低了可用性,而目前jdon采用了非即时一致性,事务软状态,使得可用性大大增强。

这和 Amazon的 Dynamo 思想是一致的:一个Dynamo框架应该是这样:逻辑随着数据分布,任何模型都可以自己持久化,这样做的优点是系统有低延迟。

当Jdon框架应用部署在分布式环境中时,模型只要向所在的服务器技术组件通过Domain Events发出持久化即可,逻辑和数据都在模型中,完全符合Dynamo框架的“符合逻辑随着数据分布”定义。

http://www.jdon.com/jivejdon/thread/37411#23125489

这里有一个Dynamo框架产品的白皮书:
White Paper: The Dynamo Application Framework - Accelerating ...


CAP原理:
Consistency(一致性), 数据一致更新
Availability(可用性), 响应性能
Partition tolerance(分区容错性) 可靠性

只可同时满足二点,没法三者兼顾。架构设计师不要精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。

关系数据库ACID模型实现了CAP原理的一致性和可靠性,但是失去了响应性能。
BASE(Basically Available, Soft State, Eventually Consistent)思想实现了CAP原理的响应性能 和一部分可靠性,降低了一致性要求。

所以,基于模型缓存的Jdon框架和Dynamo基本都属于BASE思想流派。

两者区别是,Jdon框架是基于Java世界解决方案,最终实现BASE需要结合分布式缓存如terracotta等完成,它不是一个产品BOX,而NOSQL之类的Key-Value产品是和关系数据库头碰头的产品BOX,可以适合非Java如PHP RUBY等领域,而且因为关系数据库人人皆知,所以说Key-Value可以替代它,比较容易理解和接受与实施,而如果要给出以领域驱动设计 + 分布式缓存等一系列解决方法,就不是一两句能说清楚,当然这种方式更灵活,更应该是架构师必须掌握的。



[该贴被banq于2009-11-11 17:51修改过]

2009年11月03日 11:00 "xmuzyu"的内容
如果加入异步和同步的事件处理策略就好了。
@Introduce("message")
public class MyModelEvent{

@Send("listenerName",asyc="true")
public ModelMessage xxx(){};
}

结合hibernate发现严重问题,异步之后,另开线程,hibernate绑定到当前线程的session怎么管理?
这个问题在DDD sample jdon版里面出现,下载链接:
https://jdon.dev.java.net/files/documents/3703/145210/dddsample.war

摘录自"DDD sample代码"
cargo.registerHandlingEvent(attempt);//事件发生,比如上货,下货
HandlingEventService.registerHandlingEvent();//程序异步到这个service
cargo.wasHandled(event)//注册cargo被处理
cargoInspectionService.inspectCargo()//再次异步
Delivery.derivedFrom(routeSpecification(), itinerary(),
handlingHistory);//重新通过routeSpecification计算值对象Delivery同时triggerDeliveryEvents


@Introduce("message")
public class JdonEventProcessor implements ApplicationEvents{
@Send(
"cargoHandler")
public DomainMessage cargoWasHandled(HandlingEvent event){
return new DomainMessage(event);
}
@Send(
"simpleLogging")
public DomainMessage cargoWasMisdirected(Cargo cargo){
return new DomainMessage(cargo);
}

@Send(
"simpleLogging")
public DomainMessage cargoHasArrived(Cargo cargo){
return new DomainMessage(cargo);
}
@Send(
"eventRegistration")
public DomainMessage receivedHandlingEventRegistrationAttempt(HandlingEventRegistrationAttempt attempt){
return new DomainMessage(attempt);
}

}

[该贴被oojdon于2009-11-16 17:56修改过]

2009年11月16日 17:37 "oojdon"的内容

结合Hibernate发现严重问题,异步之后,另开线程,hibernate绑定到当前线程的session怎么管理?

使用Domain Events后,可以替代Open Session In View或CLose Session In View,也就是说,Session的打开和关闭,只在MessageListerner中实现,就不能用以前的Close Session In View。

更进一步来看,持久层框架应该配合模型持久化,而不应该为了让持久化框架如Hibernate工作,模型设计将就它,不能让技术框架成为模型设计的阻碍或必须考虑的因素,说严重一点,不能让Hibernate绑架模型,这事数据库已经做过,难道要赶走豺狼,引来虎豹吗?

所以,使用Jdon框架6.2,Hibernate就不能越过模型层,在web.xml中提前打开或关闭,Hibernate Session开启和关闭只能起存储作用,如果Hibernate不能实现这点,违背我们原则,那么就要弃之不用。

oojdon你考虑一下Hibernate是否可以按照这种最佳实践模式来进行,你的DDD sample代码我也在看。多了Resource这个REST注解,好像很不错哦。