当前位置: 首页 > 编程学习 > 软件工程 > 领域驱动 > 正文

用DDD设计一个电商网站(九) 小心陷入值对象持久化的坑

2018-04-22 来源:博客园/Zachary_Fan

一、前言

在上一篇中(如何一步一步用DDD设计一个电商网站(八)—— 会员价的集成),有一行注释的代码:

    public interface IRoleDiscountRelationRepository// :    IRepository<RoleDiscountRelation>
    {
        RoleDiscountRelation Get(string roleId);
    }

其中涉及的到问题是关于值对象的持久化问题。是的,由于我们之前的设计中持久化是仅针对聚合根的:

    public interface IRepository<T> where T : AggregateRoot
    {
        string NextIdentity();
 
        void Save(T aggregate);
 
        T GetByIdentity(string identity);
    }

但是有时候难免会遇到一些需要持久化值对象的场景:

场景1:一些不属于任何聚合根的对象,本身又可以当作一个不可变的值来看待(如省市区信息等),当然的确某个地区改名了可以作为一个新的值对象来表示。那么我们在把它们建立为值对象的同时,又需要持久化到数据库。这里就如这个等级折扣。

场景2:一个聚合根的内部引用了一个值对象的集合,那么如果使用的是关系型数据库进行存储,必然需要单独存一个表。

其中场景1正好是我们Demo里遇到的场景,下面来一起阐述下我对这2个场景的理解和处理方式。

二、场景1的思考

整个问题的解决方式,首先需要梳理清楚3个基本概念:“聚合根”、“实体”、“值对象”这3者的关系。这个我在(如何一步一步用DDD设计一个电商网站(二)—— 项目架构)中有提及。因为涉及到持久化,所以我们可以再通过分析这3种对象的生命周期来帮助思考。

聚合根:独立存在的对象,是代表某个限界上下文中的一个高内聚的整体概念。他的生命周期是其所属上下文中所承担的职责的周期。

实体:无法独立存在,是聚合根的一部分,生命周期由所属的聚合根掌控。

值对象:可以独立存在,但是无法进行自我管理,可以描述任何聚合根/实体,无生命周期的概念,也可以理解为永生(无限生命周期)。

把任何一个复杂的事物化繁为简的方式就是不断的提炼,归约。动静分离就是归约的一种方式,笔者我认为在DDD中“动”就是聚合根和实体,“静”就是值对象,如果能不断的提炼出“静”的部分对于整个领域的理解复杂度是有帮助的。“动”是复杂的“似生命体”,是有寿命的;“静”是简单的“死物”,它一直存在,而且一直在那里。

因此笔者我认为只要是可独立存在的对象都可以使用Repository来持久化。那么我们的Demo中,既然已经决定将等级和折扣率建立为值对象的话,接下去的持久化要怎么做呢?请看Part Ⅳ。

三、场景2的思考

场景2里有一个比较容易踩进去的坑,为了持久化把原本设计成值对象的改为实体(特别是针对一个值对象的集合的时候,需要一个唯一表示来区分其中多个值对象)。特别特别注意,当在脑海中出现这个意识的时候,需要在思维上保证从领域建模的角度思考,而不是为了持久化。因为实体建模是一种数据化的建模方式,很大程度上收到了数据库范式的影响。这里引用[Vaughn Vernon]《实现领域驱动设计》中的4个问题:

1.我们当前建模的概念表示领域中的一个东西呢,还是只是用于描述和度量其它东西?

2.如果该概念起描述作用,那么它是否满足以下几大特征?

①它度量或者描述了领域中的一件东西。

②它可以作为不变量。

③它将不同的相关的属性组合成一个概念整体。

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

⑤它可以和其他值对象进行相等性比较。

⑥它不会对协作对象造成副作用。

3.将该概念建模成实体是不是只是持久化机制上的考虑?

4.将该概念建模成实体是不是因为它拥有唯一标识,我们关注的是对象实例的个体性,并且需要在其整个生命周期中跟踪其变化?

如果你的答案是“描述,是,是,不是”,那么此时你应该坚持用值对象。我们不应该让持久化影响到领域对象的建模。

那么我们该怎么做呢?请看Part Ⅳ。

四、避坑方式

数据库选型上在Nosql出现后,可以很好的避免了这里的持久化问题。但是弱化的关系之后导致一些查询问题需要做更多的工作去解决。并且我认为在业务复杂的电商系统中,用关系型数据库作为最终的技术选型还是最常见的一种方式。那么在使用关系型数据库的情况下,我们可以通过使用以下几种方式解决这个问题:

1.把值对象中的属性作为所属实体/聚合根的数据列来存储。

缺点:会导致数据表列数较多,在一个数据页存储的数据量变少,影响数据库表的使用性能。

2.把整个值对象序列化后作为所属实体/聚合根的数据列来存储。

缺点:出现大数据长度的列,页会导致在一个数据页存储的数据量变少,影响数据库表的使用性能。另外无法直接通过SQL来查询值对象的属性,需要自定义做反序列化操作。

3.如果是ORM类的框架,那么建立一个基类通过protected的标识列来委派这个唯一标识,但是在实际运用过程中是感觉不到这个存在的。

4.如果不是ORM框架或者本身框架支持,那么可以通过无主键的方式存入到数据表中。

缺点:是无法嵌套模型。