写点什么

DDD 领域驱动设计实战 (四)- 值对象

作者:JavaEdge
  • 2021 年 12 月 18 日
  • 本文字数:2920 字

    阅读完需:约 10 分钟

0 前言

值对象也是领域模型中的领域对象。


应尽量使用值对象建模而非实体。即便一个领域概念必须建模成实体,在设计阶段也应更偏向于将其作为值对象。因为更容易创建、测试、使用、优化和维护。

1 为什么使用值对象?

曾经我们都滥用实体建模。在用户和权限等概念进入协作领域前,实体建模并没有带来什么坏处。在项目启动时,釆用了常用的建模方式:将领域模型中所有属性映射到对应的数据库表。并且为所有属性创建 setter/getter。由于每个对象都有一个数据库主键,各个实体被组织在了一个庞大且复杂的对象网。这种建模方式是一种数据建模方式,很大程度受关系型 DB 影响,认为所有都需范式化,并通过外键关联引用。但其实全然面向实体的思维方法不仅没必要,而且还浪费开发时间。


在将领域概念建模成值对象时,应将通用语言考虑在内,这是建模值对象的首要原则。


那如何确定一个领域概念是否应该建模成一个值对象呢?

2 值对象的特征

  • 度量或描述了领域中的一件东西

  • 可作为不变量

  • 将不同的相关的属性组合成一个概念整体(Conceptual Whole)

  • 当度量和描述改变时,可以用另一个值对象予以替换

  • 可以和其他值对象进行相等性比较

  • 不会对协作对象造成副作用


当你只关心某个对象的属性时,该对象便可作为一个值对象。为其添加有意义的属性,并赋予它相应的行为。需要将值对象看成不变对象,不要给它任何身份标识, 还应尽量避免像实体对象一样的复杂性。


在设计得当时,我们可创建和传递值对象实例,甚至在用完后直接扔了。无需担心客户端对值对象的修改。一个值对象的生命周期可长可短,就像个无害的红细胞在系统中来往。


《实现领域驱动设计》对值对象的定义:通过对象属性值来识别的对象,它将多个相关属性组合为一个概念整体。DDD 中描述领域的特定方面,并且是一个没有标识符的对象。


值对象本质上就是一个集。该集合有若干如下属性


  • 描述目的

  • 具有整体概念

  • 不可修改


该集合意义是在领域建模过程中,值对象可保证属性归类的清晰和概念的完整性,避免属性零碎。

3 案例

人员实体包括:姓名、年龄、性别及所在省、市、县和街道等属性。这样显示地址相关属性就很零碎。可将“省、市、县和街道等属性”拿出来构成一个“地址属性集合”,该集合就是值对象

4 值对象的形态

4.1 业务形态

值对象是 DDD 领域模型中的一个基础对象,跟实体一样源于事件风暴所构建的领域模型,都包含若干属性,与实体一起构成聚合。


实体是业务对象,具有业务属性、业务行为和业务逻辑。值对象只是若干个属性的集合,只有


  • 数据初始化操作

  • 有限的不涉及修改数据的行为

  • 基本不包含业务逻辑


值对象的属性集虽然在物理上独立,但在逻辑上仍是实体属性的一部分,以描述实体的特征。


也有部分共享的标准类型的值对象,它们有自己的限界上下文及持久化对象,可建立共享的数据类微服务,比如数据字典。

4.2 代码形态

如果值对象是


  • 单一属性,直接定义为实体类的属性

  • 属性集,设计为类,包含具有整体概念的多个属性,这样的值对象无 ID,会被实体整体引用


比如电商系统中的 Person 用户实体:


  • 有单一属性的值对象,比如 id、name

  • 也包含多个属性的值对象,比如 address

4.3 运行形态

除数据初始化和整体替换的行为,少有更多业务行为。


比如一个用户实体可有多个收货地址,多地址序列化后可嵌入人员的地址属性。值对象创建后不允许修改,只能用另外一个值对象来整体替换。若将值对象嵌入到实体,有如下方式:

4.3.1 属性嵌入

当引用如下之一:


  • 单一属性的值对象

  • 只有一条记录的多属性值对象的实体

4.3.2 序列化大对象

当引用一或多条记录的多属性值对象的实体时。


  • 以序列化大对象方式形成的人员实体对象,收货地址值对象被序列化成大对象 JSON 串后,嵌入人员实体

4.4 DB 形态

设计值对象是期望转“数据建模为中心”为“领域建模为中心”,减少 DB 表的复杂度。

5 值对象简化 DB 的最佳实践

传统数据建模大多根据数据库范式设计,每个数据库表对应一个实体,每个实体的属性值用单列存储,一个实体主表会对应 N 个实体从表。而值对象简化了 DB 设计,多采用反范式,值对象的属性值和实体对象的属性值保存在同一 DB 实体表


比如人员和地址,要设计实体和数据模型,有如下解决方案:


  1. 把地址值对象的所有属性放入人员实体表,创建人员实体、人员数据表会破坏地址的业务含义和概念完整性

  2. 创建人员和地址两个实体,同时创建人员和地址两张表增加了不必要的实体和表,需要处理多个实体和表的关系,导致数据库复杂性剧增


有没有一种设计可使得业务含义清晰,又不让数据库变复杂?综合以上方案优势,扬长避短:


  • 领域建模时,把地址作为值对象,人员作为实体,即可保留地址的业务含义和概念完整性

  • 数据建模时,将地址的属性值嵌入人员实体数据库表,只创建人员数据库表。这既可兼顾业务含义和表达,又不会复杂化 DB


值对象就是通过该方式,简化 DB 设计:


  1. 领域建模时,将部分对象设计为值对象,保留对象的业务含义,同时又减少了实体数量

  2. 数据建模时,我们可以将值对象嵌入实体,减少实体表的数量,简化 DB 设计


要发挥对象的威力,就需优先领域建模,弱化 DB 作用,只把 DB 作为一个保存数据的仓库。即使违反 DB 设计原则,也不必大惊小怪,只要业务能顺利运行,无伤大雅。

分析

虽然优势是可简化 DB 复杂度。但若使用不当,优势就会成劣势。所以必须理解值对象的适用场景。


值对象采用序列化大对象的方式简化 DB 设计,减少实体表的数量,可简单、清晰表达业务概念。该方式虽然降低 DB 设计复杂度,却无法满足基于值对象的快速查询,导致搜索值对象的属性值变难。


值对象采用属性嵌入的方式提升了 DB 性能,但若实体引用的值对象过多,则会导致实体堆积一堆缺乏概念完整性的属性,这样值对象就会失去业务含义,操作也不方便。


所以对照优劣势并结合实际业务场景,才能发挥值对象的最大作用。

6 实体 V.S 值对象

主要区别如下:


  • 实体有唯一性,值对象没有。比如用户具有唯一性,一旦某用户被系统管理,它就被赋予了在事件、流程和操作中被唯一识别的能力

  • 实体着重唯一性和延续性,不在意属性的变化,属性全变了,它还是自己;值对象着重描述性,对属性变化敏感,属性变了,它就不是自己了

  • 实体和值对象也可能随着系统业务关注点的不同而更换位置。比如,如果另一个限界上下文更关注地址,而不关注与这个地址产生联系的人员,那就把地址设计成实体,人员设计成值对象


比如多人的单位地址是一样的,怎么处理:


  • 许多人可能属同一地址

  • 许多地址也可能属同一人


所以人和地址既可分别作为实体而把对方作为值对象,也可共同作为实体描述业务,这正是业务设计的意义,而不是非黑即白。


DDD 提倡从领域模型设计出发,而非先设计数据模型。传统数据模型设计通常一个表对应一个实体,一个主表关联多个从表,当实体表太多,就很容易陷入复杂 DB 设计,领域模型就很容易被数据模型绑架。在领域模型中人员是实体,地址是值对象,地址值对象被人员实体引用。设计数据模型时


  • 地址值对象可作为一个属性集整体嵌入人员实体

  • 也可以序列化大对象的形式加入人员的地址属性


同样一个对象在不同场景,可能设计不同:


  • 地址会被某一实体引用,只描述实体,并且其值只能整体替换,这时就可将地址设计为值对象,比如收货地址

  • 地址会被经常修改,地址作为一个独立对象存在,这时应设计为实体,比如行政区划中的地址信息


参考

  • 实体和值对象:从领域模型的基础单元看系统设计

  • 《实现领域驱动设计》

发布于: 2 小时前阅读数: 6
用户头像

JavaEdge

关注

正在征服世界的 Javaer。 2019.09.25 加入

曾就职于百度、携程、华为等大厂,阿里云开发者社区专家博主、腾讯云+社区2019、2020年度最佳作者、慕课网认证作者、CSDN博客专家,简书优秀创作者兼《程序员》专题管理员,牛客网著有《Java源码面试解析指南》。

评论

发布
暂无评论
DDD领域驱动设计实战(四)-值对象