REST & DDD 谈谈REST和DDD Repository的设计

看了很多REST的文章, 这里谈谈对REST的个人理解.

在传统的Layered Architecture中, REST的位置应该是属于Domian Layer中的Repository, 之所以这么说的原因是, REST所针对的都是名词, 例如我们针对Player这个Aggregate的Root设计的REST服务:

REST: /Player

interface PlayerRepository{
    void create(name,gender,race);
    void delete(id);
    void update(id,name,gender,race);
    void get(id);
}

可以有很强烈的感觉, Repository大部分的职责即对应了RE

ST的GET POST PUT DELETE. 可能马上就有人会提出, 如果访问二级对象, 用Repository的方式应该如何表现呢?

事实上, 在通常的DDD设计中我们操作Aggregate内其他Entity或者Value Object是需要根据Domian knowledge来决定是否拥有这些操作, 但是在REST中真正的Domain knowledge却不存在于服务端.

也许这和真正的B/S架构背道而驰, 但这正是REST精髓之所在, 松耦合的Web service才有最大的灵活性和重用性. 

REST如果承担Repository的职责那么我认为它应当单纯的执行任何具备必须权限客户端所有的CRUD请求.

REST: /Player/1/Fleet

interface FleetRepository{
    void create(player, ships);
    void delete(player, fleetId);
    void update(player, fleetId, ships);
    void get(player, fleetId);
}

 

在这里我们假设Fleet是一个player的内部entity, 它不需要全局标示符, 仅能通过player对象获取.

RESTful的精髓是将一切视作资源, 基于这一点, 我们能否在DDD是也将一切对象(Entity, Value Object)视作资源呢? 这样是否DDD中Repository也具备像Restful这样的低耦合和高度可扩展性呢?