DDD该怎么去落地实现（1）关键是“关系”

DDD落地的关键是“关系”

大家好，我是范钢老师。这些年，我认为DDD似乎走到了一个死胡同里了，因为落地实现过于困难。很多团队在经过一段时间的学习，清楚理解了DDD那些晦涩的概念，根据业务绘制出领域模型，这都不困难。但绘制领域模型不是我们最终的目的，最终的目的是基于领域模型，设计开发出业务系统。这时，很多团队就犯难了。这里面的关键问题就在于，采用DDD传统的做法，软件开发过于复杂，使得开发工作量不仅没有降低，甚至更高了。编写代码的增大，不仅使第一次的开发工作量增加，更要命的是日后变更维护的工作量增大，使得日后的维护变得困难。

采用了DDD，应当使得我们的开发变得简单，代码变得清爽，而不是代码变得臃肿。因此，我认为DDD也需要适当地变革，通过将一些通用的代码下沉底层平台，简化软件的开发。只有开发变得简单了，开发工作量减少了，DDD才能真正推行下去。我将通过一系列的文章，探讨一下DDD如何简化，我的设计思路，希望给大家带来帮助。

今天，首先谈谈模型对象间的关系，以及如何落地设计编码。在DDD的软件开发模式中，其实划分为两个阶段：基于业务的领域建模、基于领域模型的编码实现。在第一个阶段中，DDD要求我们首先深入地理解需求背后的业务，深入地掌握业务领域知识，然后将我们对业务的理解形成领域模型。在这个阶段中，我们会先划分限界上下文，将纷繁复杂的业务划分成一个一个较小的区域。然后，基于每个限界上下文的业务进行领域建模，形成如下的领域模型：

注意，在这个领域模型中，包含许多领域对象，如订单、用户、地址。每个领域对象包含各种的属性和方法，以及相互的关系。譬如，一个订单对应一个用户，但一个用户可以有多个订单，因此从订单到用户是一个“多对一”关系，有一个从订单多用户的箭头。这个箭头什么意思呢？它代表在订单对象中有一个属性是“用户”，并且是一个引用指向用户对象，落地到程序就是这样写的：

@Data
@EqualsAndHashCode(callSuper = true)
public class Order extends Entity<Long> {
    private Long id;
    private Long customerId;
    private Long addressId;
    private Double amount;
    private Date orderTime;
    private Date modifyTime;
    private String status;
    private Customer customer;
    private Address address;
    private Payment payment;
    private List<OrderItem> orderItems;
	...
}

在这个模型中，订单对象有4个箭头，指向“用户”、“用户地址”、“支付”和“订单明细”。这个箭头称为“导航”，它代表对象和对象之间的关系。然而，这些关系的类型是不一样的，从订单到用户和用户地址是“多对一”关系；从订单到支付是“一对一”关系；从订单到订单明细是“一对多”关系。

但现在的问题就在于，“一对一”和“多对一”关系，在这段代码中都是一个属性变量，我们无法从代码上区分它们到底是什么类型。同样，“一对多”关系在代码上是一个集合变量，如这里的订单，我们同样无法区分它到底是“一对多”还是“多对多”关系。也就是说，DDD要求我们将领域模型的原貌直接映射成代码实现。但真正代码实现时，仅仅写一个领域对象不能把领域对象间的关系描述清楚。所以，我们必须要在领域对象的基础上进行补充说明，来说明对象间的关系。我们通过一个DSL来描述。

DSL（Domain Specific Language，领域特定语言）是针对某个特定领域的计算机程序设计语言。在DDD中的DSL就是领域驱动设计这个特定领域的计算机设计语言，我们可以用xml、yaml、json等任何格式的文档来表达，但它表达的是领域驱动中的“对象”、“对象的属性”、“对象间的关系”，以及如何与数据库映射等相关的内容。

<do class="com.edev.trade.order.entity.Order" tableName="t_order">
    <property name="id" column="id" isPrimaryKey="true"/>
    <property name="customerId" column="customer_id"/>
    <property name="addressId" column="address_id"/>
    <property name="amount" column="amount"/>
    <property name="orderTime" column="order_time"/>
    <property name="modifyTime" column="modify_time"/>
    <property name="status" column="status"/>
    <join name="customer" joinKey="customerId" joinType="manyToOne"
         class="com.edev.trade.order.entity.Customer"/>
    <join name="address" joinKey="addressId" joinType="manyToOne"
         class="com.edev.trade.order.entity.Address"/>
    <join name="payment" joinType="oneToOne" isAggregation="true"
         class="com.edev.trade.order.entity.Payment"/>
    <join name="orderItems" joinKey="orderId" joinType="oneToMany"
         isAggregation="true" class="com.edev.trade.order.entity.OrderItem"/>
</do>

这里可以看到，通过一个xml文件，描述了订单对象的所有补充信息。在这里有订单对象的所有属性，以及它的所有关系。在这些关系中，不仅描述了每个关系的类型，还描述了它的关联属性，以及是否是聚合关系。与此同时，在这个DSL中还描述了订单对象对应的数据库表，以及每个字段对应的订单对象中的属性。有了这个DSL，才真正将领域模型的原貌映射到设计编码中。

除了设计编码，领域模型还要落地到数据库设计中。因此，DDD落地实现的关键是正确地识别领域对象间的“关系”。只有在领域建模的过程中正确地识别这些关系，才能在后面的程序编码与数据库设计中，做出正确的设计。这里的关系有“一对一”、“多对一”、“一对多”、“多对多”以及继承关系，我们一个一个来讨论吧。

首先是一对一关系。订单与它的支付就是一对“一对一”关系，一个订单只能有一个支付，而每个支付都要对应一个订单。这里其实有2个约束：每个支付必须对应一个订单，在数据库中通过一个外键来表示；一个订单只能有一个支付，这是一个唯一性约束，因此将刚才的那个外键变为了支付表的主键。最后的效果就是，订单表的主键变成了支付表的主键。通过这个主键，每条支付记录都要对应一个订单，但有些订单可能在支付表中没有记录。

值得注意的是，一对一关系的双方，到底谁指向谁，其实没有定理，必须基于相应的功能来决策。譬如，用户与会员也是一对一关系，然而应当谁指向谁呢？看后面的功能如何设计。如果将用户与会员当成彼此独立的模块，用户查询不显示会员，而会员查询却要显示对应用户，则会员指向用户；相反，如果将会员作为用户的子功能，都在用户档案中统一管理，则用户指向会员，查询用户时就能自动带出会员。当然，这样的设计会将用户指向会员的关系设计成聚合关系。

在一对一关系中，由于关系的双方都是通过主键来对应，因此在DSL中就不需要描述关联字段，只需要说明是一对一关系就行了。同时，如果是聚合关系，则在DSL中进行如下描述：

<join name="payment" joinType="oneToOne" isAggregation="true" 
 class="com.edev.trade.order.entity.Payment"/>

接着，是多对一关系，它是领域建模中最常见的关系。如订单指向用户及用户地址、订单明细指向商品，都是多对一关系。在数据库设计时，通过一个外键就可以表示多对一关系。譬如，在以上案例中，在订单表中通过用户ID、地址ID，在订单明细表再通过商品ID，就能表示这种多对一关系。

在DSL中，多对一关系需要一个关联的字段。在订单对象中有一个用户ID，它就是用户对象的关联字段，在DSL中表示如下：

<join name="customer" joinKey="customerId" joinType="manyToOne" 
 class="com.edev.trade.order.entity.Customer"/>

下一个关系是一对多关系，它实际上代表的是一种主子表的关系，如订单与订单明细、表单与表单明细、发票与发票明细。在这种关系中，订单只有一个，但它对应的订单明细却有多个。这样，在订单对象中的“订单明细”属性就不能是一个变量，而必须是一个集合变量，要么是Set，要么是List。这种关系如何映射成数据库设计呢？在数据库设计中没有一对多关系，然而将该关系倒过来，将订单明细指向订单，就变成了多对一关系。因此，在订单明细表中通过一个外键，就可以表示了。

这里就产生了一个问题了：在领域建模时，为什么不是订单明细指向订单呢？在这里实际上是一种聚合关系，订单是整体，订单明细是部分。如果设计成订单明细指向订单，那么这种聚合关系就消失了，我们必须得分别去管理订单和订单明细的增删改。在添加订单明细时，必须要检查它对应的订单是否存在；在删除订单时，也要检查它对应的订单明细是否已经被删除掉了，这样就会增大软件设计的复杂度。而将订单指向订单明细，则可以通过聚合关系将对订单明细的管理，封装在对订单的管理中。在增删改订单的同时，就在管理对订单明细的增删改，那么设计编码就得到了简化。代码简化了，日后的变更维护也就变得简单了。有了这样的设计，在编码的时候，首先将订单对象中增加一个订单明细的集合变量，然后在DSL中进行如下配置：

<join name="orderItems" joinKey="orderId" joinType="oneToMany" isAggregation="true" 
 class="com.edev.emall.order.entity.OrderItem"/>

在这里，将该关系定义为了聚合关系。但毫无疑问，这种聚合关系的实现，需要底层“仓库”的支持。譬如，在更改订单时，我们如何知道客户是否对订单明细有增删改操作呢？这些问题我们在后面的文章中再与大家探讨。除此之外，以上案例的代码详见我的仓库：

Order.jave

order.xml

除了以上三个关系以外，还有“多对多”与继承关系。这两种关系在设计上都比较复杂，我将在下一期跟大家探讨。

如果对以上内容感觉有用，欢迎关注、点赞、转发！

相关的文章：

DDD你真的理解清楚了吗？怎么准确理解“值对象”

DDD你真的理解清楚了吗？充血模型 or 贫血模型

DDD你真的理解清楚了吗？非常抽象的聚合

（待续）