EDA事件驱动架构

顺序编程非常普及，可以说是大多数程序员编程范式，只不过可能他们没有意识到，如今已经进入并发编程时代，顺序编程和并发编程是两种完全不同的编程思路，堵塞Block是顺序编程的家常便饭，常常隐含在顺序过程式编程中难以发现，最后，成为杀死系统的罪魁祸首；但是在并发编程中，堵塞却成为一个目标非常暴露的敌人，堵

2009年JdonFramework 6.2版本推出基于内存的异步领域事件版本，其关键点是Domain Model + In-memory + Domain Events.常驻内存In-memory的领域模型Domain Model通过领域事件Domain Events驱动技术实现各种功能，正如基因

文章比较全面分析了系统可伸缩性scalable设计。 首先指出scalable和普通意义上性能提升有些不同，以至于更多人关注单台机器性能，而无视更高意义上性能扩充。 Scalable可伸缩性不等同于perform

最近又重温了领域驱动设计的原著，有了一些新的理解。现在我觉得我能更好地理解jdon007之前说的下面这段话了。 “用户需求”不能等同于“用户”，捕捉“用户心中的模型”也不能等同于“以用户为核心设计领域模型”。 《老子》书中有个观点：有之以为利，无之以为用。

为什么要用事件采购Why Event Sourcing? - Blog - CQRS and Cloud Comp

看了这个帖子 http://www.jdon.com/jivejdon/thread/37712/15，深受启发。 因为我也正好碰到这个问题。比如一堆分类，每个分类需要统计其下Product的数量。 这是我的回帖

作者写了一系列Taking Baby Steps with Node.js，开始学习使用Node.js，一共有下面几个介绍1.

对象设计不是仅仅为了真实的模拟现实世界,而是使现实世界的需求能更好的在计算机这个环境中表达,当我们思考对象职责,设计对象行为时，能够更好的扩展，能够更好的维护，能够更清晰的表达这个对象所承担的职责，能够更好测试，能够有更好的性能，才是我们要达到的目标。我曾经一度对什么是正确是设计，什么是好的

以下知识是关于领域驱动设计（DDD）的, 大部分摘自flyzb的思想,虽然在很多人看来并不赞同, 但我个人认为对我启发很大. 有兴趣的可以看一下. 我一直觉得不要盲目相信权威，比如不能一谈起领域驱动设计，就一定认为国外的那个Eric Evans写的那本书中的一些概念就一定是正确的，认为领域驱

该架构的核心思想是: 1. 领域模型好比是一个实心的圆球，圆球的表层就是领域服务（Domain Service），圆球内部由各个相互平等的，没有相互依赖的，通过事件消息完成相互协作的领域对象组成；2. 领域模型应该依赖于一个中央事件处理器，该处理器

尽管RabbitMQ 和ActiveMQ提供了完整的“out of the box” 消息系统JMS: 需要配置再运行. 而0MQ则更象一个库包子系统，更加轻量，可以基于其开发自己的消息系统。 几个特点：1.socket并发框架2.跨进程携

Java EE6 Events, a lightweight

如图，订单状态有New Order，Registered，Granted，Shipped，Invoiced，Cancelled，相当复杂，在不同的状态执行操作时会产生不同的影响，比如说我们要执行AddOrderLine的话，要判断订单状态，如果是Registered或Granted状态的话，

我们当前在做一个商城的项目，当会员在付款完毕后，系统将会给用户发送一条 短信或者一个邮件（短信或者邮件由用户来自己选择，可以2者都远），来告知付款成功。目前我们的做法是把短信、邮件通知 写成一个单独的类，同步嵌入到付款类中，可我们始终觉得这么有点不妥， 请问各位，大家对于发送短信通

也许还没到达一定的知识层次，关于domain Events有疑问搞不清楚，希望道友指教 在J道逛了很长一段时间，记得以前在逛的时候，好多东西都看不懂，发现原来自已 缺少某些基础概念知识，拼命的去查找J道文章中的相

    实话说，banq的JF中的Domain events模型是非常不错的，能够让领域模型和其它层的交互隔离开来，并为提升性能提出了一条解决方案。     但同时，“JF中的Domain events模型”