Domain-Driven Design: Tackling Complexity in the Heart of Software回顾之Associations-聚合

Domain-Driven Design: Tackling Complexity in the Heart of Software回顾之Associations-聚合

顾客和售货员之间的关系说明了两个问题。首先,在开发者看来,这是两个真实的人之间所存在的一种关系。另一方面,它又表示了两个程序对象之间的一种指向关系,或者说代表一种数据库数据检索,也可能是其他的什么。

当然这种关系未必那么直接。一对多的聚合关系未必就是一个对象含有另外一个对象的集合。也许只是从数据库去查询数据,然后实例化一些基于数据的东西。当然需要从中选择一种机制才行。

在现实生活中,存在着很多的多对多关系,其中又有很多是双向多对多关联。这种关联让我们程序的实现变得相当复杂。其实,仔细想一想,这些复杂的多对多关系未必就是实用的。

现在有三种方式来简化这种关系。

1、使用有向关联。

2、使用限定词。

3、除去那些不重要的关系。

应该尽可能的给程序中的关系加上一些限制。双向关系总是意味着关联的两方互相依存。如果程序中不总是使用关联的任意一方导航到另一方,那么为关联添加方向性将会大大简化设计以及对象之间的依赖关系。如果你真的深入到领域中,你就会了解到领域本身也含有这么一种倾向。

举个例子来说。任何国家都会有领导人(总统)。这就是一种双向关联。但是在日常生活中我们往往不会这样问:里根是哪个国家的总统?而是会这样问:美国总统是谁?这就是领域本身的一种倾向。利用这种倾向,我们就可以简化总统和国家之间的关系,简化我们的设计。这代表着一种对于领域的深入理解。同时,也能让更加泛化的类“人”来作为关联对象之一。如下图:

Domain-Driven Design: Tackling Complexity in the Heart of Software回顾之Associations-聚合_第1张图片

随着我们对领域更加深入的理解,我们发现,除非非常时期,美国在一个时间阶段内只有一个总统。这又给了我们一个契机。我们可以把国家-总统这种多对一关系转化成为一种“一对一”关系(至少是有条件的多对一关系)。这同时也为我们的设计添加了一个重要规则。我们的程序可以应付诸如“谁是美国1970年总统”这样的问题了。

如下图:

Domain-Driven Design: Tackling Complexity in the Heart of Software回顾之Associations-聚合_第2张图片

 实际上部分无向的多对多关系的简化也更加突出了那些不能简化的无向多对多关系。这也突出了我们领域中的一些重要关系所代表的一些重要概念。

终极的对关系的简化就是除去关系,如果你认为这些关系对于领域而言不那么关键的话就可以这么做。

你可能感兴趣的:(Domain-Driven Design: Tackling Complexity in the Heart of Software回顾之Associations-聚合)