最近一直在思考一个问题：有没有这样一种可能，就是一个领域模型的状态不依赖于外部，它只负责接收外部的事件，然后根据这些事件做出响应；响应分两种：
1）根据模型当前的内存状态进行业务逻辑处理，然后产生事件，注意：这个过程不会改变模型当前的内存状态；
2）根据事件改变自己的状态；
另外，也是最重要的，领域模型不用关心自己所产生的事件到底怎么样了，比如不关心有没有持久化，不关心是否和别的事件有并发冲突。它只管根据自己当前的内存状态做上面这两点的响应；
如果这样的设想有可能，那领域模型就是真正的中央业务逻辑处理器了，和CPU很类似了。这样它才能真正快起来。
简单的说就是：事件->模型->事件
模型只管响应事件，然后产生新的事件
领域模型就是一黑盒，它只能帮你处理业务逻辑，其他的什么处理结果它一概不关心；当然，领域模型肯定有它自己的状态，但这个状态是驻留在内存的，和领域模型是一体的。
我为什么会有这个想法是因为，我在想，为什么要让领域模型的处理逻辑依赖于它的处理结果是否被正确顺利持久化了？感觉这很荒唐。
既然领域模型有自己的内存状态空间，他的所有逻辑也应该只依赖于这个状态空间，不再依赖于其他任何外部的东西。
当然，以前我们设计的IRepository，实际背后都是直接从数据库取。这样的话，领域模型的状态空间就是数据库了。但是这样其实很不好，因为为什么不用内存作为领域模型的状态空间呢？
现在再想想LMAX就是我刚才的想法的一个实际例子。
事件->模型->事件，这样的设计，理论上并不需要必须要求单线程来访问模型，因为领域模型不依赖于任何外部的状态，只依赖于自己所在存活内存空间；单线程有一个很大的好处就是可以防止并发冲突的产生。我们其实完全支持多线程或集群的方式，只不过这样会有可能访问到的领域对象的状态是了老的，因为不同的机器之间的领域模型内存对象的状态需要做一些同步，访问到老数据的可能性的大小取决于并发的大小以及机器之间数据同步的快慢；
LMAX之所以用单线程，是考虑了，这单线程的领域模型和性能之间，性能已经可以达到他们的要求了。
这样的架构，领域模型中的任何一个对象的一次状态更新至少会响应两个事件，举个例子：
1）先响应ChangeNoteCommand（command也是一种事件，可以理解为NoteChangeRequested），然后Note模型产生一个NoteChanged事件；
2）然后该事件（NoteChanged）最终又被发送到领域模型让其响应，此时，领域模型才去更改自己的Note状态；
经过这两个事件的响应，才完成了Note的最终状态的修改；而我们以前都是从数据库取Note，然后更改，然后保存到数据库。这样不慢才怪！
通过上面的两次事件响应，可以换来领域模型***的吞吐量。剩下的我们只要考虑：消息的序列化和反序列化、消息传递的速度、事件持久化的速度、并发冲突后重试的设计，以及消息丢失，等问题。但这些都不是领域模型该考虑的问题。这些外围的任何问题，都不要让领域模型自己去考虑，我们应该对出现的各种问题逐个寻求解决方案。
每个问题的解决方案我大概理了下我的对策：
- 消息的序列化和反序列化：这个简单，用BinaryFormatter，或更快的开源序列化组件，可以达到每秒10W次每秒；
- 消息传递的速度：用MSMQ，如果嫌太慢，就用ZeroMq，可以达到30W消息每秒；
- 事件持久化的速度：由于事件都是跟着单个聚合根，所以我们只要确保单个聚合根的事件不会冲突（即没有相同的版本号的事件）；为了更快的持久化，我们可以对事件按照聚合根或者其他方式进行分区存放，不同的服务器存放不同的聚合根；这样通过集群持久化的方式可以实现多事件同时被持久化，从而提高整体的事件持久化吞吐量；如单个mongodb server每秒持久化5000个，那10个mongodb server能每秒持久化5W个；
- 并发冲突后怎么办：一般来说就是选择重试，但为了确保不会出现不可控的局面（可能由于某种原因一直在重试），那需要设置一个***的重试次数；超过***重试次数后不再重试，然后记录日志，以供以后查找问题；这里的重试的意思是：重新找到对应该事件的command，然后再次发送该command给领域模型处理；
- 消息丢失：丢失就丢失了呗，呵呵；要是你觉得消息决不能丢失，那就用可靠的带持久化功能的消息传输队列，如MSMQ；当然，就算消息丢失了，我们很多时候都要想想有没有影响的，一般来说，消息丢失，至少我们是知道程序有问题了的，因为模型的状态此时一定是不对的。我们可以通过在消息发出时和接收时记录日志，这样方便以后查找消息是在哪个环节丢的；
- 任何其他的异常出现，这个我觉得如果都是托管代码，那可以在必要的地方加try catch，然后记录日志。至于是否要重试，还要看情形；
另外，如果是多线程访问模型，或集群访问，那很多时候访问到的内存的领域对象的状态都是老的，那怎么办？其实这不是问题，因为事件持久化的时候会被检测到这种并发重复，然后对应的command会被重试。
另外，这种架构，传输的是事件，事件都是很小的，所以不用担心消息传输的性能。
目前就想到这些。后续再完善思路，
***，我一直认为：知识决定命运，学习积累知识，而正确的思维方式是一切高效学习的基础。所以要学会如何清晰地思考！
所以，我们最重要的是要学会如何思考。
呵呵！
原文链接：http://www.cnblogs.com/netfocus/archive/2013/03/26/2982152.html
