【DDD】持久化领域对象的方法实践

最新推荐文章于 2024-10-05 19:36:07 发布

句幽

最新推荐文章于 2024-10-05 19:36:07 发布

阅读量1.4k

点赞数 5

分类专栏：领域驱动设计文章标签： c#

本文链接：https://blog.csdn.net/uoyo_blog/article/details/104689345

版权

本文探讨了在领域驱动设计（DDD）中如何实践领域对象的持久化，特别是值对象的持久化问题。文章讨论了将值对象作为字段或单独表进行持久化的优缺点，以及如何处理集合值对象的持久化。作者提到了使用如EFCore的 Owned Entity 特性，将值对象序列化为JSON字段，以及创建数据存储对象作为持久化中介。最后，文章比较了不同策略，并强调应根据项目需求选择合适的持久化方案。

摘要由CSDN通过智能技术生成

概述

在实践领域驱动设计（DDD）的过程中，我们会根据项目的所在领域以及需求情况捕获出一定数量的领域对象。设计得足够好的领域对象便于我们更加透彻的理解业务，方便系统后期的扩展和维护，不至于随着需求的扩展和代码量的累积，系统逐渐演变为大泥球（Big Ball of Mud）。

虽然领域驱动设计的思想很诱人，但我们依然会面临各种隐藏的困难，就比如今天我们要讲的主题“持久化”：即使前期我们设计了足够完整的领域对象，但是依然需要持久化它们到数据库中，而普通的关系型数据库可能很难维持领域对象的原有结构，所以我们必须要使用一些特有的手段来处理它。

开篇

本篇文章属于《如何运用领域驱动设计》系列的一个补充，如果您阅读过该系列的其它文章，您就会发现关于“持久化”的这个问题已经不止在一篇博文中提及到了。

那么，到底是什么原因让我们面临这个问题呢？是的！值对象！ 如果您认真的了解过值对象的话（如果还不了解值对象，您可以参考如何运用领域驱动设计 - 值对象），您会发现值对象是由许多基元类型构成的（比如string,int,double等），所以我们可以理解它为对细粒度基元类型的包裹，构成我们所在领域中的一个基础类型，比如说下面这个例子：

public sealed class City : ValueObject
{
   
    public string Name {
    get; }
    public int Population {
    get; }

    public City(string name, int population)
    {
   
        Name = name;
        Population = population;
    }
}

我们假设现在有一个叫做City的值对象，它是由名称（Name）和人口数量（Population）构成。通常我们这样建立值对象的原因很简单，在该领域中我们一联系到“人口”数量就会和“城市”连同在一起（你不会说我想知道人口数量，而你会说我想知道纽约的人口数量），所以“城市”这一概念成为我们该领域中的小颗粒对象，而该对象在代码实现中是由多个小基元类型构成的，比如该例子就是由一个string和一个int。

这样建模的好处之一就是我们考虑的问题是一个整体，将零碎的点构建为一个整体对象，如果该对象的行为需要发生改变，只需要修改该对象本身就可以了，而不是代码散落在各处需要到处查找（这也是滚成大泥球的原因之一）。

如果您喜欢捕猎有关DDD的知识，您可能不止一次会看到这样一条建议规则:

In the world of DDD, there’s a well-known guideline that you should prefer Value Objects over Entities where possible. If you see that a concept in your domain model doesn’t have its own identity, choose to treat that concept as a Value Object.

该建议的内容就是提倡DDD实践者多使用值对象。当然也不是说无论什么东西都建立成值对象，只是要我们多去发现领域中的值对象。

但是这往往给持久化带来了难度，先来想一下传统的编码持久化方式：一个对象（或者POCO）里面包含了各个基元类型的属性，当需要持久化时，每个属性都对应数据库的一个字段，而该对象就成为了一个表。但是这在领域驱动设计中就不好使用了，值对象成了我们考虑问题的小颗粒，而它在代码中成了一个类，如果直接持久化它是什么样子呢？表，使用它的实体或者聚合根也是一个表，两个表通过主外键关系链接。

那么这样持久化方式好不好呢？答案是不确定的，可能了解了下文的这些方案后，您会有自己的见解。

本篇文章的持久化方案都是基于关系型数据库，如果您是非关系型数据库（比如mongodb），那么您应该不会面临这样的问题。

字段 Or 表

将值对象持久化成字段好呢？还是将值对象持久化为表好呢？这个问题其实也有很多广泛的讨论，就好比.NET好还是Java好（好吧，我php天下**），目前其实也没有个明确的结果：

觉得持久化为表字段的原因是如果持久化为表，必须给表添加一个ID供引用的实体或者聚合关联，这就不满足值对象不应该有ID的准则了。
觉得持久化为表的原因是数据表模型并不代表代码层面的模型，代码里面的值对象其实并没有ID的说法，所以它是符合值对象的，而持久化为字段的话，同一个值对象数据会被复制为多份导致数据冗余。

当然哈，各有各的道理，我们也不用特别偏向于使用哪个结论。应该站在客观的角度，实际的项目需要哪种手段就根据切实的情况来选择。

来说一下持久化为字段的情况

该手段其实在近期来说比较流行，特别是在EFCore2.0之后，为什么呢？因为EF Core2.0提供了一个叫做从属实体类型的概念，其实这个技术手段在EF中很早就有了，在EF中有一个叫做Complex的东西，只是在EF Core 1.x时代没有引入而已。

在EFCore引入了Owned之后，微软那个最著名的微服务教程 eShopOnContainers 也顺势推出了用于该特性来持久化值对象的方案：

所以这也是为什么大家都在使用Owned持久化值对象的原因。（当然，大家项目中只有Address被建立为值对象的习惯不知道是不是从这儿养成的 😜）。

来看看Owned好不好使：

首先是一个实体中包含一个值对象的情况，该情况在微软的那个案例中已经实现了，所以我们不用纠结它的功能，肯定是能够实现的。

但是有其它的情况，一个实体包含了一个值对象，该值对象中又包含了另外一个值对象。您可能会问，怎么可能会有这么复杂。但是如果您按照上面那个多使用值对象的准则的话，这种情况在您的项目中非常的常见。我引用了《如何运用领域驱动设计》中的案例来测试这种实现，代码大致是这样：

public class Itinerary : AggregateRoot<Guid>
{
   
    public ItineraryNote Note {
    get; private set; }
}

public class ItineraryNote : ValueObject
{
   
    public string Content {
    get; private set; }
    public DateTime NoteTime {
    get; private set; }
    public NotePerson NotePer