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中我们会根据场景选择性的对某些特征以属性的形式加以抽象。而在我们日常消费的场景下，显然编号和发行日期这两个特征我们可以直接忽略不计。
从上面这个例子我们可用总结出值的特征：
- 表示一个具体的概念
- 通过值的属性对其识别
- 属性判等
- 固定不变
3.案例分析
购物网站都会维护客户收货地址信息来进行发货处理，一个地址信息一般主要包含省份、城市、区县、街道、邮政编码信息。
如果要让我们设计，我们肯定噼里啪啦就把代码写下来了：
/// <summary>
/// 地址
/// </summary>
public class Address {
/// <summary>
///Id
/// </summary>
public int AddressId{ get; private set; }
/// <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; }
}
}
很简单的类，我想你在没了解DDD值对像之前肯定会这样写，这并不奇怪，我之前也是这样设计的，为了将Address映射到数据库，我们需要定义一个AddressId作为主键映射，这是数据建模的结果。那在DDD中应该如何设计？别急，我们一步一步的分析。
首先，我们要问自己一个问题，地址是什么？广东省深圳市南山区高新科技园中区一路 邮政编码: 518057（腾讯大厦），它就是一个标准的地址，表述的是一个具体的不变的位置信息。它不会随着时间而变化，它包含了地址所需要的完整属性（省份、城市、区县、街道、邮政编码）信息。所以，地址是一个值。
按照我们现在的设计，如果有多个所处腾讯大厦的注册用户，我们数据库将存在多条相同的地址信息（只是Id不同）。但Id不同，就不是同一个地址吗？我们在做发货处理的时候，难道会因为Id不同，而将货物发往不同的地方吗？很显然不是的。这也再次论证了地址是一个值的事实。
那我们如何抽象设计这个地址呢，让其具有值的特征？
我们一条一条的来进行分析。
- 表示一个具体的概念
我们上面设计的Address类，也能表示出地址这个概念。 - 通过值的属性对其识别
也就是不需要唯一标识，删去我们设计的AddressId即可。 - 属性判等
重写Equals方法，比较属性判断。 - 固定不变
就是通过构造函数来初始化，所有属性均不提供修改入口。
修改后的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持久化来避免这一问题呢？
- 单个值对象
上面我们提到值对象不会孤立存在，所以我们可以将值对象中的属性作为所属实体/聚合根的数据列来存储（比如，我们可以将收货地址的属性映射到客户实体中）。这样做就会导致数据表列数增多，但是能够优化查询性能，因为不需要联表查询。 - 多个值对像序列化到单个列
当每个客户仅允许维护一个收货地址时，我们用上面的方式没有问题。但很显然一个客户可以有多个收货地址。这个时候我们该怎么持久化值对象集合呢？不可能把值对象集合的每个元素映射到外层的实体表中，但是创建多个表又增加复杂性，所以一个变态的方法是使用序列化大对象模式。把一个集合序列化后塞到外层实体表的某一列中，是有点匪夷所思。而且数据库的列宽是有限制的，且不方便查询。但似乎也带来一个好处，大大简化了系统的设计（不用设计多列分别存储了）。 - 使用数据库实体保存多个值对像
使用层超类型来赋予值对象一个委派标识，以数据库实体的形式保存值对象。（关于层超类型，可参考我上一篇文章，这里不作赘述。）
你可能会觉得第3个方法好，因为其更符合传统的设计方式，但其并非DDD推崇的一种方式，因为层超类型让值对象有了实体的影子。在进行持久化设计的时候，我们要谨记根据领域模型来设计数据模型，而不是根据数据模型来设计领域模型。
4.3.值对象的作用
通过上面的分析介绍，我们可以体会到值对象带来的以下好处：
- 符合通用语言，更简单明了的表达简单业务概念。
- 提升系统性能。
- 简化设计，减少不必要的数据库表设计。
5.建模值对象
值对象作为领域建模工具之一，有其存在的意义。领域中，并不是每一个事物都必须有一个唯一身份标识，对于某些对象，我们更关心它是什么而无需关心它是哪个。所以建模值对象，我们关键要结合通用语言的表述看其是否有值的含义和特征。
6. 总结
如果非要对值对象进行总结的话，我希望你记住我开头的那句话：
值对象=值+对象=将一个值用对象的方式进行表述，来表达一个具体的固定不变的概念。
仔细揣摩，定有收获。
