"的内容
关于LMAX，我现在已经想通他的input events，business logic processor, output events了。
business logic processor (blp)类似于ddd中的领域模型，用于处理业务逻辑；
input events，指CQRS架构中的command
output events，指domain event
然后，LMAX的input events交给blp处理前会先持久化到日志中，就是架构图中的journaler做的事情。
martin把通过input events来还原BLP的做法叫做event sourcing。实际上本质是command sourcing。因为这种做法是通过重新执行一个系统的所有的输入事件来还原系统整个状态的架构。
这种做法在关系型数据库或者redis中都是这样的做法。这种做法确实可以做到让blp非常快，且它产生的domain event甚至都不需要持久化了，因为我们已经持久化了input events了。所以LMAX架构中，通过output disruptor把output events异步分发出去。
但是，这种做法实际上是有前提的，那就是BLP的逻辑要不能改！这点非常重要，因为一旦改了逻辑，那再通过input events来还原BLP的状态就不是以前的状态了。但是像数据库SQL或者redis的命令为什么可以这样做呢？因为sql或redis的命令的处理逻辑一定是不变的，也就是相当于那种系统，只要输入是什么，那结果是什么就确定了的。
但是像我们的业务系统，领域模型的结构或者逻辑，比如一个if语句都不能改，否则就会出现无法通过input events还原BLP的风险。
所以，基于以上的考虑，我基本不会考虑使用类似LMAX的架构在DDD的应用程序中，因为我的业务逻辑不可能不修改！
因此，要实现单线程600TPS的架构，对我来说还是个传说，呵呵。
所以，我目前只能还是实现真正的event sourcing，也就是根据output events来还原BLP。这样的方式来还原BLP相对比较靠谱。因为我们的domain结构是不常改的，就算改，也可以做到和以前兼容。而逻辑的改动不影响event sourcing。而要做event sourcing，那就必须持久化domain event。所以，我才会设计为，一定是把domain event持久化完成了才认为事实发生了。