我的个人看法:我觉得之所以现在面向领域的软件设计模式不盛行,是有一定原因的,而传统设计应用的长盛不衰,经久不疲也是有一定原因的,两者不可避免都有一定的局限性,将不会存在谁被谁替代。对于传统的mvc架构程序,典型的特点是,同步,锁,关系数据库,高并发支持性不好,但是安全性强,数据一致性高(间接导致代码不够优雅),但是三层结构还是比较清晰的,分层也直接导致了web项目的高产和繁荣。传统的应用程序设计在面向企业级应用时,通常是把高安全性,数据高准确性放在第一位,而把对高并发的支持放到了第二位。有人说,传统应用真正需要高安全性,高数据一致性的仅仅是很小一部分,这个是很难界定的,也很难说清楚的,业务和业务之间的联系,数据对数据的影响,可能错综复杂,牵一发而动全身,谁敢做此保证呢? 反过来,新的面向领域设计,并发事件编程,读写分离,加入场景角色,确实和传统的应该设计有点不同,但也并不是完全新的事物。 面向领域是针对传统编程的一点改变,实际上是想把面向对象的思想重新融入到架构中。传统架构的设计是摒弃了OO思想的,就是简单明了的三层,在这一点上,是有原因的,三层结构清晰明显,解耦设计也提高了程序的扩展性,且重要的一点是高产(在目前的市场经济下,或者说是商业模式下,高产就代表着高效益高利润,这往往比其它更重要)。在这一点上,面向领域未必就占优势。面向领域了提出聚合根,高聚合的概念,这也是真正面向对象的思想,以面向对象的思维去解决问题。但是很多企业级应用的模型,无法或很难提炼出一个高聚合的结构,或者仅能提炼出很扁平的聚合结构,而大部分业务也是由这些扁平的聚合体积木式的积聚而成,它们并不需要面向对象的思想。这并不像论坛程序,或者局部小范围内的某些应用能提炼出高度聚合的结构,同时使用这种聚合结构就能实现全部或大部分业务行为。面向领域还提出一个失血模型概念,这个概念本身也是以应用中能提炼出聚合结构为依据的,但传统的企业级应用可能根本就没有提炼聚合结构,三层架构中来回传递的实体(包括持久层持久化的实体),只能算是一个简单的dto(不称为实体也许更合适,但是状态可变性未被大多数人所重视,并且不名避免的可能会引发一些意想不到的问题)而已,简单的传输对象dto,就是对一些数据碎片的封装,是不需要充血的。充血就意味着有行为,要维护状态,而传统应用设计中的这种实体是完全不需要的,因为本质是就没有领域实体的概念。面向领域,认为所有的业务或者大部分的业务都是这些聚合结构的职责,由这些聚合结构实现层层事件传递和接力。而传统应用设计,无须这些聚合结构(或者可能也根本提炼不出来),认为所有的业务职责都是操作者(人)的职责,直接由操作者发出命令,然后,三层结构以同步的方式完成命令并持久化。而面向领域,变成了操作者发出命令给聚合根,聚合根再把命令层层传递给聚合结构,最后牵出事件,异步持久化事件及最终状态。在这点上,两者无法谈孰优孰劣,也不可能是一边压倒一边。 加入场景角色,以角色驱动行为,也就是所谓的DCI。这个思想或者说设计,能更好的站在人的思维的角度(或者说哲学的角度)去诠释,解决问题。就好像当初面向对象的思想更好的站在人的思维的角度去诠释,解决问题。但是,面向对象替代不了面向过程,面向对象的编程也替代不了函数式编程。同样,dci也替代不了传统的无角色OO。就目前的情况来说,dci更适合于有聚合结构,并且聚合结构能驱动全部或大部分业务行为,且存在多场景且场景可能频繁变化的应用。这种应用说实话很少,像生物仿真,人工智能,自然语言理解与合成等应用算是此种。更多的企业级应用,往往不是面向通用场景的,仅仅是仅针对一个或少数几个领域,也就是说,场景和角色默认是已经确定了的,或者极少改变,还不至于要用到DCI来解决反复大量的场景角色变化问题。 读写分离最早是体现在数据库上,到现在为止还很少体现在架构设计上,原因可能是dao设计还没有达到需要高度抽象到读写分离的程度。也就是说,读写分离并不难于理解,只是应用到了一定程度,持久化类为了解决各自职责高度抽象的结果,最终导致读写的职责解耦,分离。 并发事件编程模型,这个思想早已有之,只是没有对高速发展的硬件(多cpu,以及多核cpu)提供支持并进行优化。并发事件编程在过去,也应用到了很多领域,但之所有在web领域的mvc中没有盛行,我想是有一定原因的。传统的企业级应用追求高安全性,高稳定性,高数据一致性准确性,这个只有使用同步和锁能解决的最简单,最好。现在的很多并发事件编程模型(包括本站的),都是把高并发性,高性能放在第一位,而高安全性,高稳定性,高数据一致性准确性放到了第二位。但这个是有风险的,大多数企业级应用不允许你这样。并发事件编程模型,确实实现了高并发的支持,解决了大访问量性能瓶颈。但我觉得,这只是在一定程度上解决了高并发访问性能瓶颈,或者可以这样说,在某种程度上,这个性能瓶颈是转移到了事件持久化及回放的复杂度上。为什么这么说呢?因为传统企业应用保存的是实体的最终状态,也就是说,我只关注结果,而不关注过程。事件编程,则必须记录事件的全过程,否则不敢对结果作出最终的正确性保证。问题是,一个很复杂的业务可能仅对一个状态做出简单的改变,或者大量复杂的业务仅改变了少数状态(也有可能最终状态没有改变)。也就是说,同等情况下,保存一个事件过程要比保存实体的状态复杂得多,可能要花费更多的空间和时间,同时还要花费更多的精力来保证这些事件能及时被持久化不丢失,保证能正确的回放,保证回放最终能真正的还原到历史上的时间点。要想完美的实现这些保证,几乎是不可能的。同时,有些企业级应用一旦发生事件,是不可逆转的,异步事件提前更改的实体状态,可能造成永久的的更改,无法抹去,也无法回放,很多金融应用都属于此类。还有一些企业级应用,涉及的领域范畴太多,一个事件,可能如蝴蝶效应般快速传染扩散到其它应用或网络服务,这种应用回放的难度太大,几乎可以认为是不能回放。除此之外,还可能有一些实时性很强的应用压根就不允许你回放。这最终导致了两个最大的难题,并发事件如何解决即时持久化大量的事件问题,如何解决异常时的回滚或者说是回放,对于那些难以回放或者不允许回放的,又如何保证其状态改变的安全性和准确性,这是否可以说是解决一个瓶颈的同时带来了一个新的瓶颈呢? 我想,这大概就是为什么面向领域的设计,并发事件编程模型未能普遍,盛行的一些原因吧