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

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

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

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

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

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

不过对于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修改过]

最近也在思考互联网上 如何能保证后端REST资源调用的安全。

期待banq老师 开帖发表高见！

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

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

呵呵，其实这些都属于面向函数风格FP。横看成岭侧成峰。

如果从CQRS的读写分离角度看，MVC一般只有在写操作情况下才可能会有用处，也就是REST的PUT/POST/DELETE操作下才可能需要MVC。准确地说，是对模型进行写操作下才需要MVC。

而在只有读操作，也就是查询功能情况下， 大部分查询涉及到几个领域模型，这种情况其实MVC已经没有效果，显得累赘而重量。

所以，从以上分析来看，MVC其实占据整个系统的分量大概是1/3，如果在服务器后端使用MVC框架，会导致整个系统被MVC绑架，而移植到客户端，无疑是明智而简单的。

将MVC移植到客户端，无论是浏览器客户端，还是手机移动原生客户端，这样后台都有一个统一的REST服务风格。

手机客户端设计：http://www.jdon.com/45605

[该贴被admin于2013-07-23 07:34修改过]

客户端MVC+REST这个架构我很赞同，但是REST连接的应该是服务端预渲染的数据结构，而不是CQRS。

举个例子，网站首页的今日热点TOP10，这有可能是新闻、微博、产品或者任意领域对象。领域对象和REST之间的渲染层将领域对象按页面区域渲染为合适的数据结构，存入NOSQL。

MVVM => REST => Present Layer => CRQS => DDD

　　　　　　　　　　　　||

　　　　　　　　　　　　v

　　　　　　　　　　NOSQL

[该贴被gameboyLV于2013-07-23 21:31修改过]

客户端MVC+REST这个架构我很赞同，但是REST连接的应该是服务端预渲染的数据结构，而不是CQRS。
<p>

赞同，出于安全的考虑，也不应该把后台的Model暴露给客户端。与客户端交互的Model只应该是渲染的数据结构

其实也不算FP，只是借鉴了FP了思想，地址是资源的标识，但是却不能保证每次资源都相同，这是违背FP的，从HTTP的四个动作get put post delete可知只有一个动作没副作用。REST实际上是回到原始的HTTP，让HTTP协议直接支持，不需要中间件。

然而，非要REST函数化是可以的，因为我们可以把资源分为fuction+states，最后变成 address->fuction+value/states->page。我们每次修改value/states = 我们每次都在修改整个函数f' (f' = f states)，而f'就是资源。我们必须认清一点，尽管每次都是同一个指向的资源，但该资源不一定跟之前一样，所以REST只能是借鉴了FP，而不是FP。

FP在WEB中很特殊，对DB的处理是基于monad的。所以想真正了解FP的现实意义，monad必须过关。

我现在有点controller恐惧证，项目中那一堆的controller越看越不爽，老师的这个帖子对我很有启发啊，前段时间jdonmvc的代码也有更新，demo代码用extjs4来做大量的客户端工作，后端代码退化为：

public class TestController {

    private static DB db = new DB();

    @In
    private RequestBody body;

    @Path("/")
    public Represent index() {
        return new Html("index");
    }

    @Path("/users")
    public Represent get() {
        return Json.create(db.all());
    }

    @Path("post:/users")
    public Represent add(User user) {
        db.add(user);
        return Json.create(new Result(true, "add success"));
    }

    @Path("put:/users/:id")
    public Represent update(int id) {
        db.update(body.json2Object(User.class));
        return Json.create(new Result(true, "update successful"));
    }

    @Path("delete:/users/:id")
    public Represent delete(int id) {
        db.del(id);
        return Json.create(db.all());
    }

    @Path("post:/upload")
    public Represent upload(FormFile formFile) {
        return Json.create(new Result(true, "upload successful"));
    }

}
<p>

后台就是一个Json构建函数

那么这个TestController有必要没？用java非要写个类，其实重点是那些打了注解的函数。所以理想应该类似这样的代码，全是函数，没有类

get "/" {
 render => index
}

get "/" {
"hello world"
}
<p>

于是我看上了sinatra，当然

app.get('/api', function (req, res) {
  res.send('Our Sample API is up...');
});

js + nodejs + 文档数据库，这是一个很酷的组合

上面的代码可在这里获得https://github.com/oojdon/mvcdemo

[该贴被oojdon于2013-07-25 12:56修改过]

好久不见，JdonMVC这次更新得好啊，REST功能更强大，JdonREST，哈哈。

查询读操作时：可以直接对DDD的Domain Service加上REST标注了，将领域服务直接暴露给外界作为API调用。

写操作命令时：可以对command handler进行REST标注。

是不是可以这么说：如果说Jdon框架是核心和组织，那么JdonMVC则壳。为理想加油。

相关：

http://www.jdon.com/45619

关于本文进一步分析：http://www.jdon.com/45622

[该贴被banq于2013-07-30 17:10修改过]

比如:一个用户(用户作为资源) CQRS中你可以有ChangePassWrord(修改密码),ChangeAddress(修改地址)等等命令,而REST中你只能是SET 整个USER