EDA事件驱动架构

应用架构设计的三个类型

前段时间在论坛回答两个问题：事务和事件，这两个概念涉及到业务和技术架构的区分问题，合适的架构解决合适的业务，就像不同运输工具装载不同的运输物一样，人用客车装载，货物用卡车装载。通过长期业务实践，我们会发现业务中隐约有一些通用共同的东西，如果我们能够总结出

业务建模：CQRS应用场景

分析了做过的一些项目（基于经典DDD），觉得应用CQRS的场景还是蛮多的，特别是当出现模块之间出现相互依赖的时候，我这里说的应用场景不是为了保证查询数据的一致性，而是由领域出发自然而然的过程。举一个例子：ERP中的物流或供应链管理会有销售模块、采购模块、库存模块、财务模块等，

实践ddd，太让人沮丧了。。

现在很沮丧啊。。。前段时间负责的项目，雄赳赳的采用领域对象的方式来建模和编写。将系统分成： controller > 粗粒度service > context > repository > dao 这几层来进行开发，同时，借鉴 dci的架构将bo的行为移到了role中。

高并发开发？？

最近看了论坛中很多关于高并发的文章，感触很多，现在我在公司就在搞后台服务器，我们使用的是ICE来进行集群管理，但是发现并发效果还一般，我觉得这样不够，就看我看到文章里说的，以后高并发是发展的趋势和潮流，我看了下“LMAX架构”，可以处理这样大的并发量，我有点不明白的就是“内存领

RRiBbit：开源事件总线EventBus框架

RRiBbit可以作为事件总线Eventbus, 能够让组件之间进行双向通讯，支持远程功能，实现失败恢复负载平衡， SSL/TLS等支持，这也称为请求-响应总线(Request-Response-Bus). 在一个大型项目中，模块之间的依赖是一个大的挑

disruptor多生产者使用问题。

我使用disruptor做性能测试。程序结构是这样的，我使用异步servlet接收请求，请求接收后就调用ForwardService.publish()方法将请求事件放入disruptor里，disruptor的消费者只是简单的结束servlet请求。我现在用jemeter起200个

混合OO和Functional设计

面向对象定位于系统高层次，面向函数编程是定位于低层次. 来自

jdon framework 为什么没有用Event Source 呢

没有发现Event Store /snapshort 之类的东东，还是没必要用

memeory image内存映像

这是MF站点的一篇新文章：MemoryImage内存映像，主要说明我们以后要改变过去和数据库打交道方式，直接和内存中领域模型打交道。鉴于

Cassandra作为事件存储的最佳选择之一

Cassandra特点是写入快，而在一个事件驱动架构EDA或Event sourcing中，我们需要一个可伸缩扩展的数据库来保存快速发生且不断增长的事件日志，将系统正在发生所有事件都进行保存，然后在适当时候进行事件回放，或者需要时进行数据挖掘分析。这其中

domain类型怎么访问数据集（dao）

如果domain不能访问dao，来获取数据，那么很多业务方法无法实现啊。这时在将业务方法移动到service层，那不是很失败？如果domain需要访问数据，那岂不是依赖dao层了？

关于事件轮询(event loop)的问题

最近看了看Node.js的东西，在单线程下执行非阻塞i/o，依据事件轮询来达到提高并发的效率。这一点可以理解。但是我深入想象内部实现，应该也是开了后台线程，对于每一个I/O操作定义的回调进行注册，然后依次执行回调方法。不知道是否是这样的，如果是这样的，那么所谓轮询，也就是后台线程做个无线循环去队列获