文章目录

概述
状态
标识
Entity 对比 VO
如何识别

概述

为了更好的理解 Entity与VO，我们需要先区分两个概念：状态、标识

状态

购物中的订单状态，相比大家都熟悉哈，比如发货中、物流派送中、商品已送达等等。一般订单状态都是使用一个字段来表示的，比如status， status不同的值代表不同的状态。

但是这个status就是「订单状态」吗？难不成状态就是一个字段吗？

我们联想一下生活中的例子

商品已经是发货「状态」了
今天「状态」不错
…

以今天「状态」不错为例，如果状态就是一个字段， status=1 状态好 status=0 状态不好。感觉不是很合理。

我们会发现，「状态」实际上表示的是「目标对象在当前时刻所呈现出的内容」！在系统设计中中通过一个字段来表示状态只是一种简化手段！

「状态」表示的是「当前时刻所呈现出的内容」，那么说明了「状态」是个快照/瞬态！也就是说，「目标对象」有多个「状态」，「当前状态」只是「目标对象」众多「状态」中的一个！

理解了什么是「状态」以后，我们就可以来初步区分Entity和VO了：

Entity在整个生命周期中，有多个「状态」，也就是说「状态」是可变的（至于变不变就看实际情况了）
而VO在整个生命周期中，只有一个「状态」，也就是说「状态」不变

对于VO来说，因为「状态」是不可变的，我们就可以用其「状态」来表示VO！但是对于Entity来说，因为有多个「状态」，且「状态」是可变的，那我们如何来表示呢？

举个例子：假设同一个买家在同一个卖家那里买了两个同样的商品，那两个订单里的信息都是一样的，但是它是两个不同的订单，我们如何区分这两个订单呢？

那就不得不提到「标识」了

标识

说到「标识」，最先想到的一般是编程语言中的「引用」或「指针」

Order orderA = new Order("productA",...);
Order orderB = new Order("productA",...);
orderA.setProductName("productB");

orderA和orderB虽然订单信息（状态）都相同，但是这是两个不同的订单 ,. 即使改了orderA的产品名称（状态），依然还是订单A。

看似解决了「区分相同状态的不同Entity」的问题，但是没有解决Entity有多个状态的问题。因为「标识」指向的是目标对象的当前状态。

语言中的这种「标识」就是无法跨系统。比如，在分布式系统中，需要保证两个系统中的对象是同一个对象，这种「隐式标识」是做不到的。

所以「隐式标识」并不能满足我们的需求。我们需要「显示标识」，「显示标识」在现实中很常见：

身份证号码就是每个人的「显示标识」
产品编号就是产品的「显示标识」
…

比如 Order

public Class Order{orderNo // 显示标识productstatus...
}

设置订单号以后，无论订单的状态如何变化，只要订单号不变，那么它就是同一个订单。

所以，「标识」是另一个区分Entity和VO的关键点：

Entity有标识
VO没有标识

注意标识并不一定只是一个字段，可能是多个字段的组合，这需要根据不同的业务逻辑来确定。

Entity 对比 VO

Entity是具有多个「状态」的对象，「状态」在其生命周期中可能会改变，通过「标识」来唯一确定这个对象
VO只有一个「状态」，且是在创建时就确定的，也就是说VO是不可变的

那么我们如何在系统中识别哪些对象是Entity，哪些对象又是VO呢？

如何识别

一个对象是表示成Entity还是VO，取决于系统的关注点

举个例子：

「商品」在「订单系统」中是个VO，而在「商品管理系统」中是Entity

在「商品管理系统」中，系统需要关注「商品」的「状态」，需要维护是否上架、库存多少、各种属性等信息（多种状态）。就是说在「商品管理系统」中，商品状态是可变的。所以它也有「标识」，即商品ID
「订单系统」并不关心「商品」的「状态」变化，它只关注在创建订单时，这个「商品」的当前「状态」是什么，并且在订单创建完成后，这个「商品」的「状态」就不会再改变了

在「商品管理系统」中，商品可以这样表示：

public class Product {id // 商品标识namedescstatus...
}

而在「订单系统」中，订单是个Entity，商品是个VO，可以这么表示：

public class Order{orderNo // 订单标识product:Productstatus...
}public class Product {id // 这里不是标识，只是状态namedescstatus...
}

注意这里的id并不是标识，这里的id实际上退化成了状态的一部分，保留这个id是为了和「商品管理系统」进行交互，通过id从商品管理系统中查询商品。当然还有其它方式，例如保存「商品管理系统」中该商品的历史URL。

DDD - 如何理解Entity与VO相关推荐

entity、vo、dto简单理解
1.概念 VO(View Object):视图对象,用于页面展示层,它的作用是把某个指定页面(或组件)的数据封装起来,传输到前端页面上. DTO(Data Transfer Object):数据传输对 ...
java实体类中有枚举类型_当实体类中entity/DTO/VO等类中，有枚举值，应该怎么输出？...
当实体类中entity/DTO/VO等类中,有枚举值,应该怎么输出? 问题: orderStatus 和 payStatus都是枚举类,并且枚举的个数达地10来个,我们不可能在模板页面(jsp/ftl ...
Java学习笔记——实体类（ENTITY，VO，DTO，BO）
最近在写代码的时候,对于Entity.VO.DTO.BO的概念有些混淆,不太了解具体的用途以及作用,所以想梳理一下. 阿里巴巴Java开发手册中的分层领域模型规约: DO(Data Object):此 ...
面试官：谈一下你对DDD的理解？我：马什么梅？
领域模型(domain model)是对领域内的概念类或现实世界中对象的可视化表示.领域模型也称为概念模型.领域对象模型和分析对象模型. --<UML和模式应用> 我们在日常开发中,经常针 ...
初学者浅谈我对领域驱动设计(DDD)的理解
一.为什么要学习领域驱动设计如果你已经设计出了优雅而万能的软件架构,如果你只是想做一名高效的编码程序员,如果你负责的软件并不复杂,那你确实不需要学习领域驱动设计. 如果用领域驱动设计带来的收获: 能 ...
pojo、entity、vo三种类的区别
pojo,entity,vo三种类的区别 pojo(Plain Ordinary Java Object):普通的Java对象,其实就是简单的JavaBean实体类.对应数据库里的某一张表,pojo里 ...
关于DDD,个人理解
个人理解: 这是一种思想,而不是框架或者技术.是指导方法, 最简单的说就是:拆分,再拆分,降低耦合度,模块内实现高内聚. 目的是: 高内聚模块之间低耦合但是,很容易搞成四不像,模块高耦合.没有边界, ...
DDD—快速理解聚合根、实体、值对象的区别和联系
聚合根.实体.值对象的关系: 1.实体具有ID,生命周期,状态用值对象描述状态,实体通过ID进行区分是这个实体还是那个实体: 2.聚合根是实体,聚合根的ID全局唯一,聚合根下面的实体的ID在聚合根内唯 ...
DDD - 聚合与聚合根_如何理解 Respository与DAO
文章目录 Pre Question 如何理解聚合和聚合根利用聚合解决业务上的原子性操作如何确定聚合和聚合根 Respository VS DAO Pre 通常情况,我们都会面临这样的一个问题: ...

DDD - 如何理解Entity与VO

文章目录

概述

状态

标识

Entity 对比 VO

如何识别

DDD - 如何理解Entity与VO相关推荐

最新文章

热门文章