领域模型中的各个“O”（浅析VO、DO、DTO、PO及其区别）

https://www.cnblogs.com/qixuejia/p/4390086.html

基础概念

VO（View Object）：视图对象，用于展示层，在Web开发中可以理解为与前端交互的对象，作用是把某个指定页面（或组件）的所有数据封装起来，但实际上对于不与前端交互的数据，比如数据创建和修改的时间等字段，出于减少传输数据量大小和保护数据库结构不外泄的目的，不应该在 VO 中体现出来。（一般不要复用，因为VO出现的目的之一就是解耦）
DTO（Data Transfer Object）：数据传输对象，之前EJB的概念，如今泛指用于展示层(Controller)和服务层(Service)之间的数据传输对象。
DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。
PO（Persistent Object）/阿里开发规约中的DO（Data Object）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。
POJO（Plain Ordinary Java Object）：简单的Java对象，指那些没有从任何类继承、也没有实现任何接口，没有被其他框架侵入的java对象。

之间的一些区别

VO和DTO

其实VO和DTO在实现层面很多情况下字段是一致的，但是在设计理念的角度去看，DTO代表服务层需要接收的数据和返回的数据，而VO代表展示层需要显示的数据；而且，API 服务需要使用的 DTO 就可能与 VO 存在差异。（例如，VO里边可能需要展示：帅哥、美女，而DTO传递的可能只是0、1）

DTO和DO

DTO是展示层和服务层之间的数据传输对象（可以认为是两者之间的协议），而DO是对现实世界各种业务角色的抽象，这就引出了两者在数据上的区别，例如UserInfo和User，对于一个getUser方法来说，本质上它永远不应该返回用户的密码，因此UserInfo至少比User少一个password的数据。而在领域驱动设计中，DO不是简单的POJO，它具有领域业务逻辑。
为什么不在服务层中直接返回DO呢？首先，两者在本质上的区别可能导致彼此并不一一对应，一个DTO可能对应多个DO，反之亦然，甚至两者存在多对多的关系。其次，DO具有一些不应该让展示层知道的数据。而且DO具有业务方法，如果直接把DO传递给展示层，展示层的代码就可以绕过服务层直接调用它不应该访问的操作，对于基于AOP拦截服务层来进行访问控制的机制来说，这问题尤为突出，而在展示层调用DO的业务方法也会因为事务的问题，让事务难以控制。而从设计层面来说，展示层依赖于服务层，服务层依赖于领域层，如果把DO暴露出去，就会导致展示层直接依赖于领域层，这虽然是单向依赖，但这种跨层依赖会导致不必要的耦合。

DO和PO

DO和PO在绝大部分情况下是一一对应的，PO是指含有get/set方法的POJO，但某些场景还是能反映出两者在概念上存在本质的区别：
DO在某些场景下不需要进行显式的持久化，例如利用策略模式设计的商品折扣策略，会衍生出折扣策略的接口和不同折扣策略实现类，这些折扣策略实现类可以算是DO，但它们只驻留在内存，不需要持久化到持久层，因此，这类DO是不存在对应的PO的。
同样在某些场景下，PO也没有对应的DO，例如老师Teacher和学生Student存在多对多的关系，在关系数据库中，这种关系需要表现为一个中间表，也就是对应有一个TeacherAndStudentPO的PO，但这个PO在业务领域没有任何现实的意义，它完全不能与任何DO对应上。而在
某些情况下，为了某种持久化策略或者性能的考虑，一个PO则可能对应多个DO，反之亦然。例如客户Customer有其联系信息Contacts，这里是两个一对一关系的DO，但可能出于性能的考虑，为了减少数据库的连接查询操作，把Customer和Contacts两个DO数据合并到一张数据表中。反过来，如果一本图书Book，有一个属性是封面cover，但该属性是一幅图片的二进制数据，而某些查询操作不希望把cover一并加载，从而减轻磁盘IO开销，同时假设ORM框架不支持属性级别的延迟加载，那么就需要考虑把cover独立到一张数据表中去，这样就形成一个DO对应多个PO的情况。
PO的某些属性值对于DO没有任何意义，这些属性值可能是为了解决某些持久化策略而存在的数据，例如为了实现“乐观锁”，PO存在一个version的属性，这个version对于DO来说是没有任何业务意义的，它不应该在DO中存在。同理，DO中也可能存在不需要持久化的属性。

总结

一般的数据传递是，前端传递VO给接口（Controller），接口将VO转为DTO传递给service，service将DTO分解为DO，调用领域服务进行调度，然后逆向转为VO或者其他的返回结果，传递给页面。设计层面和实现层面完全是两个独立的层面，即使实现层面通过某种技术手段可以把两个完全独立的概念合二为一，在设计层面我们仍然需要把概念上独立的东西清晰地区分开来。