Domain Events异步应用-2

原文 http://www.jdon.com/jivejdon/thread/37712/15

 

Bang
按照你的逻辑，是不是我可以理解成，系统启动时，载入messageCount和第一次调用这个函数的时候载入的区别呢。

不是系统启动，而是当客户端访问Account的getMessageCount这个事件时。

一般传统观点是，一次请求事件，对应一次响应结果，一般都是想在一次请求把所需要的结果全部获得，就象贪心馋嘴的小孩吃糖果一样，现在就不同了，搞清楚你所要结果的主次，先获得主要的，次要的再来一趟获取。

所以，getMessageCount要两次触发调用，第一次触发调用是激活查询或计算事件，第二次触发调用是获得计算结果。

这个类似专门JOB异步模式适合那些费时的计算和查询，再往上就可以使用hadoop等云计算 来对付。

但是，千里之行，始于足下，你必须首先分辨出你的业务哪些是费时费力的，而且不能将这些耗CPU计算推给数据库，然后再在架构设计上专门对待。

 

 

由于针对messageCount有一些专门操作，我们就不能直接在Account中实现这些操作，可以使用一个专门值对象实现

这里也体现了一个DDD 实践中什么时候使用值对象的一个原则，当围绕这些值字段有一些专门复杂操作时，就有必要独立出来做一个值对象，最近InfoQ 2009一个讲座就是谈这个问题的：Power Use of Value Objects in DDD

他使用了电话号码为例子，因为在Action和Service中都涉及phoneNumber处理，所以，专门成立一个phoneNumber的值对象，如下：

 

 

 

 

 

Domain Events还可以实现懒加载大数据的预加载。

比如图片，只有显示图片时才会需要图片的二进制数据，这个数据比较大，所以，一般从持久层加载图片时，只加载图片其他核心文字信息，如图片ID，名称等，当需要显示时，再加载二进制数据输出真正图片。

下面是JiveJdon 的上传图片代码：

public

 byte[] getData() {
		byte[] bytes = super

.getData();
		if

 (bytes != null

)
			return

 bytes;
		preloadData();
		bytes = (byte[]) imgDataAsyncResult.getEventResult();
		this

.setData(bytes);
		return

 bytes;
	}

//预加载




public

 void

 preloadData() {
    if

 (imgDataAsyncResult == null

 && domainEvents != null

)
	imgDataAsyncResult = this

.domainEvents.loadUploadEntity(this

);
}

上面preloadData可以在控制帖子显示的Action中预先调用一下，当帖子被输出到浏览器中时，帖子再通过html语法img调用上述getData数据，显示图片。

所以，html语法显示图片本身的异步 性和我们服务器端异步 结合在一起，这种模式可以适合大量图片显示场合。

特点是：显示快，因为当浏览器发出html的img语法调用服务器的图片时，服务器端图片一般已经预加载完成，准备就绪，只能调用，这比img语法到达服务器端时再进行图片大数据加载更有效。

该模式不但适合图片，也适合任何大数据对象。

参考并发策略可以解决延迟

 

 

传统意义上，懒加载和异步 都是好像不被人接受的，会带来比较差的性能，高延迟性，属于边缘技术，这其实是被误导了：并发策略可以解决延迟

懒加载和异步 代表的并发策略实际是一种潮流趋势，特别是作为并行计算语言Scala和erlang的新亮点：
函数式编程functional programming的特点

而最新发布JiveJdon 3.9使用传统Java，基于Jdon框架6.2实现了领域模型层的懒加载和异步 ，可以完全克服Hibernate等ORM框架带来的Lazy懒加载错误问题。

 

JiveJdon3.0源码下载：http://www.jdon.com/jdonframework/download.html

 

在领域知识内不存在计算机技术的概念，你为什么要把技术层引入到DOMAIN呢

这是对的，但是因为Java语言的限制，如果采取基于Scala的Akka那种Actor Model ，而一个领域模型实际就是一个Actor，就非常自然了。Actor只能通过发送异步 消息和其他Actor通讯联系，这种消息发送是异步 的，属于“fire-and-forget”方式。


怎 样让领域模型驱动技术为其服务，不否认有更优雅的方式，权宜之举由领域模型发出事件消息不失是一种办法，而如果你将服务注射到领域模型，就不是一种事件驱 动架构（当然，还要将更多技术注射到领域模型）。而Domain events相当于只注射一次，首先建立一个事件通道，以后就可以通过这个管道让Domain一次次发送事件消息来命令技术架构为其做事，相当于在两者之 间建立一个管道。

个人认为这是一种模拟Scala的Actor模型做法。

 

领域对象，仅仅关注自身和其他领域对象之间关系的建立，至于一切计算机领域的概念，都不应该出现在领域对象中，因为这是违背自然规律的组合，或者说是违背业务概念的。

非常赞同，让领域对象纯净，也是我的一个目标，这也是DDD 提出后，没有很多具体实现要求，因为目前具体实现离DDD 要求还很远。

就像是DCI架构 中所谈论的一样，我们现在很多OO 可能是因为被OO 实现所误导了。

关键是我们寻找到一个理想和现实结合之处，而不被实现误导，我也相当有兴趣讨论，包括自我批判挖掘。可另外开贴于你切磋。

 

相关参考：
Jdon框架异步 Domain Events实现内部原理：
使用future实现内置 异步 API

对象的职责