Domain Events异步应用-2
原文 http://www.jdon.com/jivejdon/thread/37712/15
按照你的逻辑，是不是我可以理解成，系统启动时，载入messageCount和第一次调用这个函数的时候载入的区别呢。
不是系统启动，而是当客户端访问Account的getMessageCount这个事件时。
一般传统观点是，一次请求事件，对应一次响应结果，一般都是想在一次请求把所需要的结果全部获得，就象贪心馋嘴的小孩吃糖果一样，现在就不同了，搞清楚你所要结果的主次，先获得主要的，次要的再来一趟获取。
所以，getMessageCount要两次触发调用，第一次触发调用是激活查询或计算事件，第二次触发调用是获得计算结果。
这个类似专门JOB异步模式适合那些费时的计算和查询，再往上就可以使用hadoop等云计算 来对付。
但是，千里之行，始于足下，你必须首先分辨出你的业务哪些是费时费力的，而且不能将这些耗CPU计算推给数据库，然后再在架构设计上专门对待。
这里也体现了一个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
这是对的，但是因为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
对象的职责