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

13-07-20 banq

#MVC模式 #DDD领域驱动设计 #CQRS架构 #RESTful

具体来说，前端浏览器：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修改过]

#MVC模式 #DDD领域驱动设计 #CQRS架构 #RESTful

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方式推送过来” 符合“程序要能处理文本流，因为这是最通用的接口”。

有3页 1 2 3 下一页