为什么要使用MVC+REST+CQRS架构

banq 13-07-20
                   

具体来说,前端浏览器:angular.js等MVC框架;后端: REST+ CQRS。

angular.js等MVC框架是指前端浏览器的MVC框架,而不是类似Struts 或SpringMVC之类的服务器端后端MVC框架。

关于后端MVC框架的问题可见《MVC模式已死 》http://www.jdon.com/38448
基于任务的UI(Task-Based UI)

服务器端的MVC框架主要问题是粒度太粗,只能适合传统的CRUD简单粗放的应用,当我们的软件系统转向以用户体验为主,而不是以企业自身资源管理为主的模式时,响应式设计必然拥有良好的用户感受,而传统后端MVC固定的框架针对大量客户端并发事件处理无疑是力不从心,想象一下,用户鼠标一移动就可能发出一个事件,这么多事件如果每个都走Model-View-Controller这样一个流程,仅Controller就要编制多少?编程成本极高,维护拓展起来很不方便。

将MVC框架移植到浏览器前端(Rich Client),则可以巧妙回避以上问题,javascript的函数风格使得其处理事件来得更简单,对于围绕模型的操作则可以使用MVC实现。见:JavaScript大型可扩展的设计模式,而模型则是从后端领域层以JSON方式推送过来。

后端架构是:REST+CQRS,将REST和CQRS组合在一起成为CQREST架构。

REST的好处是针对资源进行简单轻量的操作,REST核心两个概念是资源和状态,而我们可以认为这个资源实际就是领域模型,通常是DDD领域驱动设计中的聚合根Aggregate,而状态是则是聚合根的状态,驱动状态变化的是REST的POST/PUT/GET/DELETE四个方法。这样REST和DDD无缝吻合在一起了。

再看看REST的四个方法实际也分两种类型:读和写。其中POST/PUT/DELETE属于对领域模型资源进行写操作的命令,属于CQRS的Command路线;而GET属于客户端发出Query查询,属于CQRS的Query读路线。
这样REST又和CQRS无缝吻合在一起。

我曾经在《没有人真正理解REST or HTTP》http://www.jdon.com/41716中说:
将来是否有一种技术思想,将DDD REST以及面向函数三者完美捆绑一起,通过URL代表领域模型类图的结构关系,比如/forum/thread,代表Forum类的子类Thread,领域模型被显式地用URL表达出来,用户访问形式和我们分析设计的模型合二为一,大道至简。

而时隔两年的今天已经实现了:《使用Yoga灵活实现REST》http://www.jdon.com/45544

如果说DDD的领域模型是核心,那么REST就是核心外的轻量壳,而CQRS则是壳和核心之间的组织,三者如有机体一样天然组合在一起,简单,易用,灵活,可伸缩,易于维护。

从缓慢的历史变化中我们应该发现一个主脉方向:MVC + REST + CQRS,如此坚定一路走来,无疑他们代表未来一种即将普及的主流架构风格。

参考:
J2EE死了 javacript + 后端JSON服务方式胜出 :http://www.jdon.com/44690
CQREST英文: http://prezi.com/svfmvrx9dq_x/cqrs-and-rest/
使用 Angular.js, Node.js 和 MongoDB开发简单案例:http://www.jdon.com/45599
[该贴被admin于2013-07-20 19:21修改过]

                   

11
banq
2013-07-20 16:48

2013-07-20 16:09 "@banq
"的内容
如果说DDD的领域模型是核心,那么REST就是核心外的轻量壳,而CQRS则是壳和核心之间的组织,三者如有机体一样天然组合在一起 ...


这个“鸡蛋”只是我个人心中目前完美的架构,如果要再披上UI这层彩衣,我认为windows 8带来的Metro风格相当于将这个外表有点土的鸡蛋变成“彩蛋”。

windows 8的Metro风格比苹果模拟真实效果的风格好处是:它将用户脑中的模型直观化简单化,而我们使用DDD领域驱动分析是将用户脑中的模型取出来变成代码,现在又有了Metro风格的展示,这样,我们就可以将领域模型直接用Metro UI联系在一起。

例如:一个紫红色方框代表后端领域层的一个聚合的根实体模型,而紫红色方框中的更多信息则是内存中实体的实时状态,这样可以将业务模型实体信息通过Metro UI的框直接显示出来。

如果说苹果的拟真更倾向于外部的操作用户,那么Metro 则更倾向于内部的模型,能够引导用户。




jdon007
2013-07-20 21:54

2013-07-20 16:09 "@banq
"的内容
如果说DDD的领域模型是核心,那么REST就是核心外的轻量壳,而CQRS则是壳和核心之间的组织,三者如有机体一样天然组合在一起,简单,易用,灵活,可伸缩,易于维护。 ...



与这个帖子的观点基本一致。如果条件允许,我会尽量采用这种方式进行开发与协作。

不过对于REST与DDD的关系,个人有不同的看法。REST API是领域模型一种极其简洁的描述方式,相对传统的数据建模或Eric Evans的对象建模(DDD),其更易于理解、交流与协作。

REST API最易于勾勒出领域模型的灵魂,但有时候它看起来太简单,以至于我们可能漫不经心,随意为之。而个人认为,这恰恰是最值得精心雕琢的地方。提炼一组有效的描述领域模型的REST API,做到API最小、最少,但又相当完善,即“增之一分则太胖,减之一分则太瘦”,并不容易。

REST API将服务的实现与接口彻底分离,一套相同的REST API,其实现可以使用Java、.NET、PHP等各种各样语言,其数据存储可以使用NoSQL或SQL各种各样的数据库。

不依赖于具体的语言、具体的数据库,其实现可以自由替换,这难道不是领域模型该具有的特征吗?看看那些UML类图、交互图,看看那些聚合根、值对象,再看看那些表、视图、外键等等,这些描述方式,有哪一种可以比REST API更简单易懂,更易于交流与协作?

REST API不仅给服务的实现者自由,也给服务的使用者自由,客户端可以是Android(Java), iOS(Object-C), WP7(C#)或Browser(Html/css/js)等等。

除了以更易于交流与协作和提供给实现者和使用者更多的自由,由于REST API本身具有正交组合的特征,其对业务的切分,自然且与现实相吻合。试问,对象建模、数据建模,要做到这点容易吗?至少要比REST API困难的多。

之前那个小小的图书馆领域建模,有如此之多的争议,不是DCI、DDD这些工具不好,可能是用错了地方,相对于REST API其更适合于领域建模的实现,而不是领域建模本身(描述接口)。

总的说来,我更提倡这样的架构: 【MVC --> Ajax <=========>REST <-- DCI】。
[该贴被jdon007于2013-07-20 21:55修改过]

hbbbs
2013-07-21 12:57

赞同banq老师的这种架构。

最近也在思考互联网上 如何能保证后端REST资源调用的安全。
期待banq老师 开帖发表高见!

[该贴被hbbbs于2013-07-21 12:59修改过]

tecentID36F90
2013-07-21 15:56

文章写的很好,受教了。另外,发现一些有趣的事情,即文中所提出的架构、方向和方法,惊人地和 UNIX 哲学符合。

首先,我们先来了解一下 UNIX 编程哲学中的三个原则:

1)一个程序只做一件事情,并做好。

2)程序要能协作。

3)程序要能处理文本流,因为这是最通用的接口。

在输入输出方面,UNIX 传统极力提倡采用简单、文本化、面向流、设备无关的格式。在经典的 UNIX 下,多数程序都尽可能采用简单过滤器的形式,即 将一个输入的简单文本刘处理为一个简单的文本流输出。

抛开世俗眼光,UNIX 程序员偏爱这种做法并不是因为他们仇视图形用户界面,而是因为如果程序不采用简单的文本输入输出流,它们就极难衔接。

然后,仔细想想就会发现,文中提出的架构惊人地符合了这三个准则。看,“命令查询的责任分离Command Query Responsibility Segregation (简称CQRS)模式是一种架构体系模式,能够使改变模型的状态的命令和模型状态的查询实现分离” 符合 “一个程序只做一件事情,并做好”;“REST API将服务的实现与接口彻底分离,一套相同的REST API,其实现可以使用Java、.NET、PHP等各种各样语言,其数据存储可以使用NoSQL或SQL各种各样的数据库” 符合 “程序要能协作”,“将MVC框架移植到浏览器前端(Rich Client),则可以巧妙回避以上问题,javascript的函数风格使得其处理事件来得更简单,对于围绕模型的操作则可以使用MVC实现。见:JavaScript大型可扩展的设计模式,而模型则是从后端领域层以JSON方式推送过来” 符合“程序要能处理文本流,因为这是最通用的接口”。

3Go 1 2 3 下一页