领域服务在戏说领域驱动设计中的应用有何特点？

本文共计4195个文字，预计阅读时间需要17分钟。

实体对象和值对象都已完成，接下来想开始写资源库。不过，没有一点烦躁的是，我不太想将工作单元单独成章来写，一是这东西网上相关内容太多；二是有的时间。

　　实体对象和值对象都写完了，本想开始写资源仓库顺便把工作单元再搞搞。不过有一点麻烦的是我不太想把工作单元作为单独的一章来写，一是这东西网上相关的内容太多；二是有的时候使用Spirng的事务就解决了，没觉得有多大作用。不过先不纠结这些，还是按本章的主题写领域服务吧，这好讲，谁不喜欢简单的东西。

一、为啥引入领域服务

　　要说原因吧，其实也挺简单的。在开发过程中你会发现有些方法不知道放哪个对象身上合适，比如说经典的转账业务：放客户对象上不合适，客户对象中没有余额的概念；放账户上面吧，感觉也差了点意思，这里涉及到了两个对象的变化而且都需要进行存储，比如您的代码可能会这样写“a.transfer(b)”，一般在开发时最好别在方法中直接修改参数的值，只你自己用或看也许问题不大，别人要使用的时候谁会想到参数也会被方法变更？JDK里那么多方法，虽然没统计过但我感觉几乎很少出现方法改参数的情况。还有的时候，一些方法所做的事情不是业务逻辑而是转换，比如根据参数构建领域实体，这种糙活谁谁都不愿意干。哪个对象都有自己的矜持与骄傲，你让他干这些活，那是看不起人家。总而言之吧，涉及跨领域对象操作、对象转换以及没人愿意干的活时交给领域服务这个老好人就妥了，这家伙是系统中的中间人、和事老。可您不能小瞧人家，领域服务也有自己的体面的，干得活再杂也是BO层中的大佬，DAO、应用服务都得围着人家转呢。而且，你别看他不起眼儿，关键时间方能显出英雄本色，要不然你的代码就是一坨那个……

二、领域服务的责任

　　BO层中有些东西虽然看着不重要，可不能简单的轻看人家，干得活绝对不含糊。您看上面这个图，领域服务要干得事儿也不少呢。