DDD与数据事务脚本

扯淡

相信点进来看这篇文章的同学，大部分是因为标题里面的“DDD”所吸引！DDD并不是一个新技术，如果你百度一下它的历史就会知道，实际上它诞生于2004年，到现在已经18年，完全是个“古董”，软件开发技术日新月异，DDD确显得很独特，一直不温不火，也未淘汰。有些人为了使用DDD“苦思冥想”、有些人对它保持敬畏，觉得是一种高端的技术，当然也有人觉得这玩意垃圾根本没用。废话不多说. 下面我尝试使用一个最基本的业务场景来讨论下ddd和事务脚本。

假如我们的现在需要做这么一个系统，名字叫做“消息发送系统”。系统里面存在很多用户，而我们需要做的，就是给指定的用户发送消息

用户能在收件箱中看到收到的消息，消息有已读，未读状态，消息内容不能为空。
通过发送用户id、消息内容，就可以发送到用户。注意这里并没有发件人的概念。

数据事务脚本

需求很简单,现在我们开始设计这个功能。相信你只需要学习过一些基本的编程技术，你第一直觉一定会整理出下面这个数据结构



    message{

        id , //消息id

        userId ,//接受用户id

        content ,//消息内容

        state ,//消息状态已读，未读

        ...

    }

当设计出这个数据结构的时候，我们心里面其实认为这个系统的“核心”就完成了，这TM是真简单啊！为什么会是这样？我们都知道，计算机最核心的组件是cpu，而cpu就是用来计算处理用户输入的数据，并将结果反馈给用户。而软件运行在计算机上，所能提供的功能实际上也是这样处理数据。当然了，计算机还有磁盘，磁盘可以存储用户输入cpu的数据，也能存储cpu处理完后的数据！按这个逻辑，一个软件（系统）实际上就是在将特定业务场景下的数据输入计算机，计算机处理完后存储这些数据。软件只需要准确的记录下计算过程中产生的所有数据，并正确的存储算据即可实现对应的功能。

软件的不同功能，只是以合适的方式创建、修改、展示数据。上面的message结构，准确的找出了我们“消息发送系统”里面产生的数据。发送消息，只不过就是新增了这样一个消息数据，而用户看消息，只是找到所有message中userid为自己的id的消息，显示出来就可以了。这个“消息发送系统”非常简单，其实大的系统也是一样，大系统由很多这样小的系统组成，本质确是一样的。

我们已经找出这个系统会产生的数据结构，当然还需要保存起来，假设将它存入数据库里面（如果你愿意，你也可以存到文件里，或者干脆只放到内存里），那么我们在数据库里面就新建一张message的表，字段就是id,userId,content,state。假设现在有个页面，您可以在这个页面中输入id，userid，content，state,点击提交按钮，软件取到这些值，就写入数据库。伪代码大概是这样：

    var id = input('id');

    var userId = input('userId');

    var content = input('content');

    if(userId == ""){

        err "userid不能为空"

    }

    if(content == ''){

        err "内容不能为空";

    }

    //发送消息

    state = input('state');

    database.exeSql("insert into message values(id,userid,content,state)");

    //查看消息

    messages = database.exeSql("select * from message where userid=userid");

这个时候“大神”告诉你，这个太low了，逻辑和操作数据库全部写一起了，一点都不面向对象，一个类都没有，你应该封装一个message类。我们现在有orm框架，能直接将对象存到数据库，这个时候你经过不断的学习，你写出了下面的代码：

    id = input('id');

    userId = input('userId');

    content = input('content');

    if(userId == ""){

        err "userid不能为空"

    }

    if(content == ''){

        err "内容不能为空";

    }

    state = input('state');

    //发送消息

    message = new message(id,userid,content,state);

    orm.save(message);

    //查看消息

    messages= orm.getMessageByUserId(userid);

简单到爆,一切都这么自然，很完美这样你的消息系统就完成了。当然了， “大神”还会告诉你，或者你自己意识到下面这些“硬核知识点”

将上面message这种跟数据库表对应的对象，称之为PO（Persistent Object）
将存储message到数据库，或者从数据库中通过相应的条件查找、更新、删除、message对象的功能，封装到一起，叫做dao对象
前端页面里不同的功能点，最好别直接调用DAO操作存储数据，因为还有一些业务逻辑代码需要编写，为了封装性，需要将不同的功能点封装到不同的类里面，我们叫做sevice类（可能很多同学直接一个数据表对应一个po，对应一个dao,对应一个service），比方说messageServcie

class messageServcie{

    message[] getMessageBuUserId();//通过用户id，获取它收到的消息

    readMessageById(messageId);//将message设置为已读

}

写了这么多，相信大家也看出来了，这就是所谓《数据事务脚本》开发方式的来源。这种开发方式很直接也很简单。如果你问我有什么问题？我觉得没什么问题，挺好的。我们以数据为中心，软件只是在处理数据，存储数据而已。

接下来我们说DDD

由于我们所使用的编程语言java、C#等，都是面向对象编程的，也很认可面向对象编程的好处！而数据事务脚本开发方式，核心是数据，虽然里面也有po对象，但是po对象却没有任何行为，这让很多人觉得有点尴尬！而ddd确说我们的领域对象是有相应的行为的，这也是很多人喜欢ddd的理由。

我们知道对象包括属性和它的行为。而软件，从面向对象的角度，就是在业务范围内设计不同的对象，然后通过对象与对象之间的行为调用，改变对象的状态，从而实现不同的功能，想想我们的现实世界，确实是由一个一个的物体组成的。汽车是不同的零部件组成，人由不同的器官组成，这也是为什么说面向对象更加容易理解，更加流行的原因。下面还是以消息发送系统为例。

通过阅读上面“消息发送系统的”需求，应该很容易发现消息，用户这些名词。暂且不管对不对，先将这些写成类

 class message{

    id , //消息id

    userId ,//接受用户id

    content ,//消息内容

    state//消息状态已读，未读

    message(id,userId,content){

        if(userId == ""){

            err "这消息不行"

        }

        if(content == ""){

            err "这消息不行"

        }

        state = "未读";

        this.id=id;

        ....

    }

    ///修改消息状态

    setState(state){

        if(this.state == "已读" && state=="未读"){

            err "已读的消息，不能设置成未读"

        }

        this.state = state;

    }

}

class user{

    id,

    userid,

    messages[],//收件箱中的消息

    addMessage(message){

        message.userid= this.userid;

        this.messages.add(message);

    },

    //将消息设置为已读

    setMessageisReaded(message){

        message.setState("已读");

    }

}

class userService{

    //发送消息

    sendMessage(id,userid,content,state){

        var message = new message(id,userid,content,state);

        var messageBox = findUserMessageBox(userid);//找到收件箱对象

        messageBox.add(message);

    }

    //获取用户收件箱中的消息

    getMessageByUserId(userId){

        var user = findUserByUserId(userid);

        return user.messages;

    }

    //将消息设置为已读

    setMessageisReaded(userId,message){

        var user = findUserByUserId(userid);

        user.setMessageisReaded(message);

    }

}

大家看了上面的代码觉得怎么样？是不是感觉也很自然，对象有自己的属性和对象。这个时候相信有些看到这里的同学，已经有疑问了“你这是搞着玩吧，数据都不存到数据库的？”。上面说过从面向对象编程的角度，软件就是对象与对象的交互，交互完后对象状态会改变，比如下说上面的发送消息代码，我们可以理解为：新创建了一个message对象，通过userid找到用户，然后将message放到用户收到的消息列表中。假如我们的内存是无限的，而且不会丢失，我们还需要存数据吗？现实当然内存不无限，也会丢失，那么是不是把这个message对象和user对象通过某种方式保存到磁盘，需要的时候取出来就可以了？存储方式很多比如你直接json序列化写到文件，写到MongoDB，或者存到关系型数据库。但是这里与数据事务脚本概念已经不一样，数据事务脚本存的是软件运行产生的结构数据，而这里存的是对象，这一点一定要理解。所谓的repository就是用来存取对象,dao却是用来存结构化数据,概念有很大的不同!!!

如果你看过一些ddd的文章，你一定知道ddd里面有很多名词：统一语言、事件风暴、限界上下文、领域、子域、支撑域、聚合、聚合根、实体、值对象。初学者一看，尼玛吓死人这么多的东西！然后就是一脸懵逼。实际上面这些词是可以分类的，有些是告诉你怎么和客户沟通，了解需求，有些是告诉你怎么划分不同子系统，有些是告诉你怎么找到设计对象，有些实际上只是给有特征的对象起个名，有些是给对象与对象的关系起个名。

对于一般开发着来说，找到对象、设计对象才是我们最关心的，因为对象是开发者写代码的基础！至于跟客户沟通、了解需求、划分不同的子系统、对象关系命名这种东西暂且放放！ ddd之所以不普及，不是因为需求没沟通好，子系统没划分好，而是因为不知道怎么设计对象，就不知道应该怎么写代码。对象是一个抽象的东西。有些系统里的对象，是有实物对应的，比如说购物车，我们就很清楚知道有什么属性和行为。而有些没实物对应，就不知道怎么找到对象，也不知道对象应该具有什么行为。一个简单的功能，每个开发者都有不同的理解与抽象，出现不同的设计方案，而且大家都认为自己的合理的。园子里有很多高手写的ddd文章，如果只是解释介绍上面的名词，一般讨论不起来，只有点赞、叫好的份。因为上面这些名词解释可以说是死的，大家能看懂就行，但是如果出现一些ddd设计案例，就会出现一些不同的设计方案来讨论。而最终当然也是不了了之！上面我写的消息发送系统代码，初学者一看觉得写的挺好，但是ddd高手一定有不认同的地方！

对象的行为如何划分

对于ddd 对象设计来说，最纠结的是行为应该放到哪个对象? 举个烂大街的例子“图书管理系统”中，读者借书的逻辑，应该设计到哪个对象。一种常见的设计是这样：

    ///读者

    class reader{

        id,

        ///名字，地址，余额，借书记录

        其他属性...

        ///借书

        borrow(book){

             //判断能不能借这本书的一系列逻辑...

            book.setState('已借');

        }

    }

    //书(这里没有定义书数量，假设书都是一本一本)

    class Book{

        id,

        title,

        state,//已借出，未借出

        setState(state){

            if(this.state == "已借" && state == "已借"){

               err "不能再借了";

            }

        }

    }

    class readerService{

        borrow(readerId,bookId){

            book = getBookById(bookId);

            reader = getReaderById(readerId);

            reader.borrow(book);

        }

    }

从代码上能看出借书逻辑写到了reader（读者）对象上,“读者借书”所以借书应该就写到读者上，很符合现实和直觉。但是这里我们需要再仔细思考下。现实世界中对于读者去图书馆借书，实际上是这样的，读者向图书馆申请借书，图书馆查看图书是否可以借给这个读者（可能这本书已经借出，也有可能这个用户不能借书...），如果能，就将书借给这个读者，然后记录一下,借书业务就完成了。如果你觉得这个描述是对的，那么借书的逻辑还应该放到reader这个对象上吗？显然不是，借书的主要逻辑应该图书馆,或者是图书管理员（取决于业务复杂程度），读者只是一个驱动者！上代码。

    ///读者

    class reader{

        id

        ///名字，地址，余额，借书记录

        其他属性...

    }

    //书

    class Book{

        id,

        title,

        state,//已借出，未借出

        setState(state){

            if(this.state == "已借" && state == "已借"){

               err "不能再借了";

            }

        }

    }

    class BookLibrary{

        borrow(readerId,bookId){

            reader = getReaderById(readerId);//找到这个读者

            book = getBookById(bookId);//找到这本数

            //检查这个读者能不能借这本书...

            book.setState("已借");//将书设置为已借

        }

    }

看上去差不都，实际上也差不多！呵呵... 但是借书这个逻辑不再放到了读者对象上，而是放到了BookLibrary上面。

再举些例子：

“银行账号转账”, 转账逻辑显然也不是账号(account)上面的，账号的行为的主要是这2个：充值（钱变多）和消费(钱变少)。至于转账应该是“银行”的功能！！！
“论坛用户发帖”, 发帖逻辑也不应该是用户对象上，而应该是论坛本身！
“用户购物”,购物逻辑也不应该是用户对象上的，这是购物软件本身通过操作账号钱包对象，物品，等等一系列对象达到购物这个目的。

...

这种例子很多，其实这里最主要是。不能将业务逻辑简单的放到驱动者身上，而是要深入分析一个功能点具体是怎么实现的，是有哪些对象一起交互才完成的功能。如果全部放到驱动者身上，最终会导致好像所有的功能都应该写到"用户"这个对象上，因为是用户在使用驱动软件。用户通过操作软件界面上的功能点，驱动软件运行。其实往往出现在软件界面上面的功能点，都应该写到这个软件本身对象（BookLibrary）这个对象上。软件本身再操作不同的领域对象，实现功能！！！这也就是ddd中所谓application services的来源，将不同类型的功能通过services概念在封装到一起，形成不同的***Service，取名叫做领域服务对象。那有人可能又会说，这样下去是不是所有的业务都到了service里面，其实不是，其他对象有自己的业务逻辑，service需要操作不同的领域对象，实现不同的业务，比方说：银行转账中，账户充值消费就是账号这个行为的，这里面就应该对账号是不是已经被冻结，余额是否足够消费，进行业务处理。

其实还有一种简单方法来设计对象，面向对象编程一开始就告诉了我们：对象=属性+行为，通过行为修改属性来到达改变对象状态实现不同的功能。也就是说行为跟对象属性是有关联性的,这也是面向对象中所谓的"内聚"。

如果一个行为跟这个对象上的属性没有任何关联，这个行为放到这个对象上就是不合适的，
如果一个行为需要好几个对象，而把功能放到这好几个对象中其中一个对象上也是不合理的。可以通过service的方式实现，还有一种方式就是将这个行为独立抽象出一个对象（这取决与业务需要）,而这个对象拥有其他需要的对象，比分说银行转账



class transfer{

    //执行转账

    execute(fromAccout,toAccount,amount){

        if(this.check(fromAccout,toAccount)){

            fromAccout.sub(amount);

            fromAccout.add(amount);

        }

        err '不能转';

    }

    //检查是否能转

    check(fromAccout,toAccount){

        //一系列的检查

    }

}

对于借书这个场景来说，一个借书流程需要，读者对象，书对象，以及一些借书规则，这些信息，这里面任何一个对象都不具备所有信息，比如说，读者对象并不知道读书对象现在是什么状态，也不知道借书有哪些规则。所以将借书逻辑放到读者对象上是不合适的。

相信对于找出对象的属性一般没问题，所以可以通过先找出对象的属性，然后再通过属性找出它的行为！！！

restfull资源与对象的不匹配

ddd之所以这段时间变得火，主要是因为微服务。大家都说使用ddd能给微服务带来多少好处（可能最大的好处是能分出不同的子系统（微服务）），我这里说一个它的坏处。

按照ddd的思路，最终出来的是一个一个的对象。而rest出来的api是一个一个的资源。ddd每个对象是有不同行为的，而rest中却规定，对于资源的操作应该是统一的(post,delete,get,put)。对象中不同的行为，应该怎么在rest中表达？从这个角度来说，ddd与restfull天然需要做一次适配，而ddd与远程对象调用更加合拍（ejb,wcf等）

而如果是传统的数据事务脚本，数据很容易对应到rest中的资源，对于数据的操作无非就是（增，删，查,改），也容易对应到（post,delele,get,put）。

总结

写了这么多，从数据事务脚本的由来，到ddd，再写到怎么设计对象。总的来说就下面几点！

数据库事务脚本:service-->dao这种方式也挺好，并不是不行！！甚至跟rest配合起来更加“直接”。这也是为什么现在大部分还是数据事务脚本方式的原因（代码中有repository，有domian可不一定是ddd哦）
在ddd对象设计中不能将业务逻辑简单放到驱动者身上，应该仔细思考，到底发生了什么，不能为了充血而充血！可以通过先找对象属性，然后再找关联的业务行为。但是前面也说了，每个人可能抽象出不同的对象,如果对象符合行为和属性内聚这个特性，建议一定要有自信别乱想（这也是很多人纠结的地方）...
ddd与restfull并不是完美匹配的。

当然这只是抛砖引玉，实际上ddd是一套完整的软件开发流程，并不只是设计对象而已，在实际开发中也还有很多的问题需要思考，比如存储对象，应该放到service中吗？发送邮件，发送短信这些功能点，写到领域对象，还是service里面，类似的问题很多！！这里不讨论,这需要大家的开发经验实践，或者去查看一下大神的最佳实践。就这样了，希望对大家有帮助，谢谢阅读！