如下是我收集到的一些资料

一位同行的见解:

      面向领域是针对传统编程的一点改变，实际上是想把面向对象的思想重新融入到架构中。传统架构的设计是摒弃了OO思想的，就是简单明了的三层，在这一点上，是有原因的，三层结构清晰明显，解耦设计也提高了程序的扩展性，且重要的一点是高产（在目前的市场经济下，或者说是商业模式下，高产就代表着高效益高利润，这往往比其它更重要）。在这一点上，面向领域未必就占优势。面向领域了提出聚合根，高聚合的概念，这也是真正面向对象的思想，以面向对象的思维去解决问题。但是很多企业级应用的模型，无法或很难提炼出一个高聚合的结构，或者仅能提炼出很扁平的聚合结构，而大部分业务也是由这些扁平的聚合体积木式的积聚而成，它们并不需要面向对象的思想。这并不像论坛程序，或者局部小范围内的某些应用能提炼出高度聚合的结构，同时使用这种聚合结构就能实现全部或大部分业务行为。面向领域还提出一个失血模型概念，这个概念本身也是以应用中能提炼出聚合结构为依据的，但传统的企业级应用可能根本就没有提炼聚合结构，三层架构中来回传递的实体（包括持久层持久化的实体），只能算是一个简单的dto（不称为实体也许更合适，但是状态可变性未被大多数人所重视，并且不名避免的可能会引发一些意想不到的问题）而已，简单的传输对象dto，就是对一些数据碎片的封装，是不需要充血的。充血就意味着有行为，要维护状态，而传统应用设计中的这种实体是完全不需要的，因为本质是就没有领域实体的概念。面向领域，认为所有的业务或者大部分的业务都是这些聚合结构的职责，由这些聚合结构实现层层事件传递和接力。而传统应用设计，无须这些聚合结构（或者可能也根本提炼不出来），认为所有的业务职责都是操作者（人）的职责，直接由操作者发出命令，然后，三层结构以同步的方式完成命令并持久化。而面向领域，变成了操作者发出命令给聚合根，聚合根再把命令层层传递给聚合结构，最后牵出事件，异步持久化事件及最终状态。在这点上，两者无法谈孰优孰劣，也不可能是一边压倒一边。

加入场景角色，以角色驱动行为，也就是所谓的DCI。这个思想或者说设计，能更好的站在人的思维的角度（或者说哲学的角度）去诠释，解决问题。就好像当初面向对象的思想更好的站在人的思维的角度去诠释，解决问题。但是，面向对象替代不了面向过程，面向对象的编程也替代不了函数式编程。同样，dci也替代不了传统的无角色OO。就目前的情况来说，dci更适合于有聚合结构，并且聚合结构能驱动全部或大部分业务行为，且存在多场景且场景可能频繁变化的应用。这种应用说实话很少，像生物仿真，人工智能，自然语言理解与合成等应用算是此种。更多的企业级应用，往往不是面向通用场景的，仅仅是仅针对一个或少数几个领域，也就是说，场景和角色默认是已经确定了的，或者极少改变，还不至于要用到DCI来解决反复大量的场景角色变化问题。

读写分离最早是体现在数据库上，到现在为止还很少体现在架构设计上，原因可能是dao设计还没有达到需要高度抽象到读写分离的程度。也就是说，读写分离并不难于理解，只是应用到了一定程度，持久化类为了解决各自职责高度抽象的结果，最终导致读写的职责解耦，分离。

并发事件编程模型，这个思想早已有之，只是没有对高速发展的硬件（多cpu，以及多核cpu）提供支持并进行优化。并发事件编程在过去，也应用到了很多领域，但之所有在web领域的mvc中没有盛行，我想是有一定原因的。传统的企业级应用追求高安全性，高稳定性，高数据一致性准确性，这个只有使用同步和锁能解决的最简单，最好。现在的很多并发事件编程模型（包括本站的），都是把高并发性，高性能放在第一位，而高安全性，高稳定性，高数据一致性准确性放到了第二位。但这个是有风险的，大多数企业级应用不允许你这样。并发事件编程模型，确实实现了高并发的支持，解决了大访问量性能瓶颈。但我觉得，这只是在一定程度上解决了高并发访问性能瓶颈，或者可以这样说，在某种程度上，这个性能瓶颈是转移到了事件持久化及回放的复杂度上。为什么这么说呢？因为传统企业应用保存的是实体的最终状态，也就是说，我只关注结果，而不关注过程。事件编程，则必须记录事件的全过程，否则不敢对结果作出最终的正确性保证。问题是，一个很复杂的业务可能仅对一个状态做出简单的改变，或者大量复杂的业务仅改变了少数状态（也有可能最终状态没有改变）。也就是说，同等情况下，保存一个事件过程要比保存实体的状态复杂得多，可能要花费更多的空间和时间，同时还要花费更多的精力来保证这些事件能及时被持久化不丢失，保证能正确的回放，保证回放最终能真正的还原到历史上的时间点。要想完美的实现这些保证，几乎是不可能的。同时，有些企业级应用一旦发生事件，是不可逆转的，异步事件提前更改的实体状态，可能造成永久的的更改，无法抹去，也无法回放，很多金融应用都属于此类。还有一些企业级应用，涉及的领域范畴太多，一个事件，可能如蝴蝶效应般快速传染扩散到其它应用或网络服务，这种应用回放的难度太大，几乎可以认为是不能回放。除此之外，还可能有一些实时性很强的应用压根就不允许你回放。这最终导致了两个最大的难题，并发事件如何解决即时持久化大量的事件问题，如何解决异常时的回滚或者说是回放，对于那些难以回放或者不允许回放的，又如何保证其状态改变的安全性和准确性，这是否可以说是解决一个瓶颈的同时带来了一个新的瓶颈呢？