DDD理论学习系列——案例及目录


1.引言

提到值对象,我们可能立马就想到值类型和引用类型。而在C#中,值类型的代表是strut和enum,引用类型的代表是class、interface、delegate等。值类型和引用类型的区别,大家肯定都知道,值类型分配在栈上,引用类型分配在堆上。

那是不是值类型对应的就是值对象,引用类型对应的就是实体吗?很抱歉,不是的。

值对象我们要分开来看,其包含两个词:值和对象。值是什么?比如,数字(1、2、3.14),字符串(“hello world”、“DDD”),金额(¥50、$50),地址(深圳市南山区科技园)它们都是一个值,这个值有什么特点呢,固定不变,表述一个具体的概念。对象又是什么?一切皆为对象,是对现实世界的抽象,用来描述一个具体的事物。那值对象=值+对象=将一个值用对象的方式进行表述,来表达一个具体的固定不变的概念

所以了解值对象,我们关键要抓住关键字——

2.值的特征

1就是代表数字1,“Hello DDD”就是一个固定字符串,“¥50”就是表示人民币50元。假设你手上有一沓钞票,我们去超市购物的时候,很显然我们会根据面额去付款,不会拿20元当50元花,也不会把美元当人民币花,毕竟¥50≠$50。那对于钞票来说,我们怎么识别它们,无非就是钞票上印刷的数字面额和货币单位。你可能会说了,每张钞票上都印有编号,就算同样面额的毛爷爷,那它也不一样。这个陈述,我竟然无言以对。但我只想问你,你平时购物付款,是用编号识别面额的啊?编号显然是银行关心的事,与我们无关。

我们这里提到的数字面额、货币单位和编号,除此之外还有发行日期,其实都是钞票的基本特征,在coding中我们会根据场景选择性的对某些特征以属性的形式加以抽象。而在我们日常消费的场景下,显然编号和发行日期这两个特征我们可以直接忽略不计。

从上面这个例子我们可用总结出值的特征:

  1. 表示一个具体的概念
  2. 通过值的属性对其识别
  3. 属性判等
  4. 固定不变

3.案例分析

购物网站都会维护客户收货地址信息来进行发货处理,一个地址信息一般主要包含省份、城市、区县、街道、邮政编码信息。

如果要让我们设计,我们肯定噼里啪啦就把代码写下来了:

    /// <summary>
/// 地址
/// </summary>
public class Address { /// <summary>
///Id
/// </summary>
public int AddressId{ get; set; } /// <summary>
/// 省份
/// </summary>
public string Province { get; set; } /// <summary>
/// 城市
/// </summary>
public string City { get; set; } /// <summary>
/// 区县
/// </summary>
public string County { get; set; } /// <summary>
/// 街道
/// </summary>
public string Street { get; set; } /// <summary>
/// 邮政编码
/// </summary>
public string Zip { get; set; }
}
}

很简单的类,我想你在没了解DDD值对像之前肯定会这样写,这并不奇怪,我之前也是这样设计的,为了将Address映射到数据库,我们需要定义一个AddressId作为主键映射,这是数据建模的结果。那在DDD中应该如何设计?别急,我们一步一步的分析。

首先,我们要问自己一个问题,地址是什么?广东省深圳市南山区高新科技园中区一路 邮政编码: 518057(腾讯大厦),它就是一个标准的地址,表述的是一个具体的不变的位置信息。它不会随着时间而变化,它包含了地址所需要的完整属性(省份、城市、区县、街道、邮政编码)信息。所以,地址是一个值。

按照我们现在的设计,如果有多个所处腾讯大厦的注册用户,我们数据库将存在多条相同的地址信息(只是Id不同)。但Id不同,就不是同一个地址吗?我们在做发货处理的时候,难道会因为Id不同,而将货物发往不同的地方吗?很显然不是的。这也再次论证了地址是一个值的事实。

那我们如何抽象设计这个地址呢,让其具有值的特征?

我们一条一条的来进行分析。

  1. 表示一个具体的概念

    我们上面设计的Address类,也能表示出地址这个概念。
  2. 通过值的属性对其识别

    也就是不需要唯一标识,删去我们设计的AddressId即可。
  3. 属性判等

    重写Equals方法,比较属性判断。
  4. 固定不变

    就是通过构造函数来初始化,所有属性均不提供修改入口。

修改后的Address如下:

   /// <summary>
/// 地址
/// </summary>
public class Address
{
/// <summary>
/// 省份
/// </summary>
public string Province { get; private set; } /// <summary>
/// 城市
/// </summary>
public string City { get; private set; } /// <summary>
/// 区县
/// </summary>
public string County { get; private set; } /// <summary>
/// 街道
/// </summary>
public string Street { get; private set; } /// <summary>
/// 邮政编码
/// </summary>
public string Zip { get; private set; } public Address(string province, string city,
string county, string street, string zip)
{
this.Province = province;
this.City = city;
this.County = county;
this.Street = street;
this.Zip = zip;
} public override bool Equals(object obj)
{
bool isEqual = false;
if (obj != null && this.GetType() == obj.GetType())
{
var that = obj as Address;
isEqual = this.Province == that.Province
&& this.City == that.City
&& this.County == that.County
&& this.Street == that.Street
&& this.Zip == that.Zip;
}
return isEqual;
} public override int GetHashCode()
{
return this.ToString().GetHashCode();
} public override string ToString()
{
string address = $"{this.Province}{this.City}" +
$"{this.County}{this.Street}({this.Zip})";
return address;
}
}

至此,我们的Address就具有了值的特征,我们可以直接使用Address address = new Address("广东省", "深圳市", "南山区", "高新科技园中区一路 ", "518057");)来表示一个具体的通过属性识别的不可变的位置概念。在DDD中,我们称这个Address为值对象。读到这里,你可能会觉得值对象也不过如此,也可能会有一堆问题,但请稍安勿躁,我们继续讲解。

4.DDD中的值对象

通过上面对值的特征分析,结合实际的案例,我们设计出了一个Address这个值对象。那在DDD中对值对象又是怎样描述的呢?

4.1.值对象的特征

咱们来看看《实现领域驱动设计》上是如何定义的吧:

  • 描述了领域中的一件东西
  • 不可变的
  • 将不同的相关属性组合成了一个概念整体
  • 当度量和描述改变时,可以用另外一个值对象予以替换
  • 可以和其他值对象进行相等性比较
  • 不会对协作对象造成副作用

由此可见,值对象包含了值所具有的全部特征。

另外有一点:个人认为值对象不会孤立的存在,它有其所属。比如我们所说的地址,它是一个客观存在。没有一个具体的上下文语境,它就仅仅是一个字符串。只有在某个具体的领域下,才有其实质意义,比如客户收货地址、售后地址。

4.2.值对象的问题

说到问题,你可能想到的第一个问题就是持久化的问题。是的,值对象没有标识列如何存储数据库呢?

当下比较流行使用ORM持久化机制,使用ORM将每个类映射到一张数据库表,再将每个属性映射到数据库表中的列会增加程序的复杂性。那如何使用ORM持久化来避免这一问题呢?

  1. 单个值对象

    上面我们提到值对象不会孤立存在,所以我们可以将值对象中的属性作为所属实体/聚合根的数据列来存储(比如,我们可以将收货地址的属性映射到客户实体中)。这样做就会导致数据表列数增多,但是能够优化查询性能,因为不需要联表查询。
  2. 多个值对像序列化到单个列

    当每个客户仅允许维护一个收货地址时,我们用上面的方式没有问题。但很显然一个客户可以有多个收货地址。这个时候我们该怎么持久化值对象集合呢?不可能把值对象集合的每个元素映射到外层的实体表中,但是创建多个表又增加复杂性,所以一个变态的方法是使用序列化大对象模式。把一个集合序列化后塞到外层实体表的某一列中,是有点匪夷所思。而且数据库的列宽是有限制的,且不方便查询。但似乎也带来一个好处,大大简化了系统的设计(不用设计多列分别存储了)。
  3. 使用数据库实体保存多个值对像

    使用层超类型来赋予值对象一个委派标识,以数据库实体的形式保存值对象。(关于层超类型,可参考我上一篇文章,这里不作赘述。)

你可能会觉得第3个方法好,因为其更符合传统的设计方式,但其并非DDD推崇的一种方式,因为层超类型让值对象有了实体的影子。在进行持久化设计的时候,我们要谨记根据领域模型来设计数据模型,而不是根据数据模型来设计领域模型

4.3.值对象的作用

通过上面的分析介绍,我们可以体会到值对象带来的以下好处:

  • 符合通用语言,更简单明了的表达简单业务概念。
  • 提升系统性能。
  • 简化设计,减少不必要的数据库表设计。

5.建模值对象

值对象作为领域建模工具之一,有其存在的意义。领域中,并不是每一个事物都必须有一个唯一身份标识,对于某些对象,我们更关心它是什么而无需关心它是哪个。所以建模值对象,我们关键要结合通用语言的表述看其是否有值的含义和特征

6. 总结

如果非要对值对象进行总结的话,我希望你记住我开头的那句话:

值对象=值+对象=将一个值用对象的方式进行表述,来表达一个具体的固定不变的概念

仔细揣摩,定有收获。


参考资料

应用程序框架实战十六:DDD分层架构之值对象(介绍篇)

DDD领域驱动设计(二) 之 值对象

值对象的威力

DDD理论学习系列(7)-- 值对象的更多相关文章

  1. DDD理论学习系列(6)-- 实体

    DDD理论学习系列--案例及目录 1.引言 实体对应的英语单词为Entity.提到实体,你可能立马就想到了代码中定义的实体类.在使用一些ORM框架时,比如Entity Framework,实体作为直接 ...

  2. DDD理论学习系列(8)-- 应用服务&领域服务

    DDD理论学习系列--案例及目录 1. 引言 单从字面理解,不管是领域服务还是应用服务,都是服务.而什么是服务?从SOA到微服务,它们所描述的服务都是一个宽泛的概念,我们可以理解为服务是行为的抽象.从 ...

  3. DDD理论学习系列(10)-- 聚合

    DDD理论学习系列--案例及目录 1.引言 聚合,最初是UML类图中的概念,表示一种强的关联关系,是一种整体与部分的关系,且部分能够离开整体而独立存在,如车和轮胎. 在DDD中,聚合也可以用来表示整体 ...

  4. DDD理论学习系列(11)-- 工厂

    DDD理论学习系列--案例及目录 1.引言 在针对大型的复杂领域进行建模时,聚合.实体和值对象之间的依赖关系可能会变得十分复杂.在某个对象中为了确保其依赖对象的有效实例被创建,需要深入了解对象实例化逻 ...

  5. DDD理论学习系列(12)-- 仓储

    DDD理论学习系列--案例及目录 1. 引言 DDD中Repository这个单词,主要有两种翻译:资源库和仓储,本文取仓储之译. 说到仓储,我们肯定就想到了仓库,仓库一般用来存放货物,而仓库一般由仓 ...

  6. DDD理论学习系列(13)-- 模块

    DDD理论学习系列--案例及目录 1. 引言 Module,即模块,是指提供特定功能的相对独立的单元.提到模块,你肯定就会想到模块化设计思想,也就是功能的分解和组合.对于简单问题,可以直接构建单一模块 ...

  7. DDD理论学习系列——案例及目录

    目录 DDD理论学习系列(1)-- 通用语言 DDD理论学习系列(2)-- 领域 DDD理论学习系列(3)-- 限界上下文 DDD理论学习系列(4)-- 领域模型 DDD理论学习系列(5)-- 统一建 ...

  8. DDD分层架构之值对象(层超类型篇)

    DDD分层架构之值对象(层超类型篇) 上一篇介绍了值对象的基本概念,得到了一些朋友的支持,另外也有一些朋友提出了不同意见.这其实是很自然的事情,设计本来就充满了各种可能性,没有绝对正确的做法,只有更好 ...

  9. DDD理论学习系列(2)-- 领域

    DDD理论学习系列目录 1. 引言 领域一词,主要有以下两个意思: 一国主权所达之地. 学术思想或社会活动的范围. 不管是指国家的主权范围也好还是学术活动范围,都是在讲一个范围,一个界限. 比如我们常 ...

随机推荐

  1. bzoj4031 [HEOI2015]小Z的房间

    Description 你突然有了一个大房子,房子里面有一些房间.事实上,你的房子可以看做是一个包含n*m个格子的格状矩形,每个格子是一个房间或者是一个柱子.在一开始的时候,相邻的格子之间都有墙隔着. ...

  2. Angular简易分页设计(一):基本功能实现

    (首先声明本文来自博客园本人原创,转载请说明出处.欢迎关注:http://www.cnblogs.com/mazhaokeng/p/6752990.html) 之前网站的后台管理为了图快,把Jquer ...

  3. 解决oracle用户锁定

        故障现象: SQL> connect scott/scottERROR:ORA-01017: invalid username/password; logon deniedSQL> ...

  4. 手把手教你学SVN

    注意 转载须保留原文链接(http://www.cnblogs.com/wzhiq896/p/6822713.html  ) 作者:wangwen896 整理 对于很多新手来说,SVN 代码托管一无所 ...

  5. vue之nextTick全面解析

    vue的第一篇文章,介绍一下简单的nextTick方法的实现原理 简介 vue是非常流行的框架,他结合了angular和react的优点,从而形成了一个轻量级的易上手的具有双向数据绑定特性的mvvm框 ...

  6. 升讯威微信营销系统开发实践:(5) Github 源码:微信接口的 .NET 封装。

    微信开发系列教程,将以一个实际的微信平台项目为案例,深入浅出的讲解微信开发.应用各环节的实现方案和技术细节. 本系列教程的最终目标是完成一个功能完善并达到高可用性能指标的微信管理软件,所以除了与微信本 ...

  7. 17、Map接口及其常用子类(Hashtable、HashMap、WeakHashMap)

    17.Map接口 Map没有继承Collection接口,Map提供key到value的映射.一个Map中不能包含相同的key,每个key只能映射一个value.Map接口提供3种集合的视图,Map的 ...

  8. 关于Cookie安全性设置的那些事

    一.标题:关于Cookie安全性设置的那些事 副标:httponly属性和secure属性解析 二.引言 经常有看到XSS跨站脚本攻击窃取cookie案例,修复方案是有httponly.今天写出来倒腾 ...

  9. PHP 关于timezone问题

    Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use ...

  10. 我和 flow.ci 的第一次亲密接触

    编者按:本文转载自 flow.ci 用户 @君赏 的实践分享,原文链接这里. 这不是第一次听说 flow.ci ,记得当时 fir.im 新出这个服务的时候,我也是心情十分激动的去尝试,结果是只支持安 ...