聚合仓库与工厂傻分不清楚海量资源.pdfVIP

本文由简悦SimpRead转码，原文地址

上一讲，我们知道了，要将领域模型最终转换为程序设计，可以到3种类型的对象设计，即服务、

实体与值对象，然后进行一些贫血模型与充血模型的设计思路。但这远远不够，还需要有聚合、仓库与

工厂的设计。

聚合的设计思路

聚合是领域驱动设计中一项非常重要的设计与概念，它表达的是真实世界中那些整体与部分的关系，比

如订单与订单单与表单明细、与明细。以订单为例，在真实世界中，订单与订单明细

本来是同一个事物，订单明细是订单中的一个属性。但是，由于在关系型数据库中没有办法在一个字段

中表达一对多的关系，因此必须将订单明细设计成另外一张表。

尽管如此，在领域模型的设计中，我们又将其还原到真实世界中，以“聚合”的形式进行设计。在领域模

型中，即将订单明细设计成订单中的一个属性，具体代码如下：

publicclassOrder{

privateSetItemsitems;

publicvoidsetItems(SetItemitems){

this.items=items;

}

publicSetItemgetItems(){

returnthis.items;

}

……

}

有了这样的设计，在创建订单的时候，将不再单独创建订单明细了，而是将订单明细创建在订单中；在

保存订单的时候，应当同时保存订单表与订单，并放在同一事务中；在查询订单时，应当同时查

询订单表与订单，并将其装配成一个订单对象。这时候，订单就整体在进行操作，不需

要再单独去操作订单明细。

也就是说，对订单明细的操作是封装在订单对象的设计实现。对于客户程序来说，去使用订单对象

就好了，这就包括了作为属性去订单对象中的订单明细，而不再需要关注它是如何操作的。

按照以下思路进行的设计就是聚合：

当创建或更新订单时，在订单对象中填入或更新订单的明细就好了；

当保存订单时，只需要将订单对象作为整体去保存，而不需要关心订单数据是怎么保存的、保存到

哪几张表中、是不是有事务，保存数据库的所有细节都封装在了订单对象；

当删除订单时，删除订单对象就好了，至于如何删除订单明细，是订单对象的实现，外部的程

序不需要关注；

当查询或装载订单时，客户程序只需要根据查询语句或ID查询订单对象就好了，查询程序会在查

询过程中自动地去补填订单对应的订单明细。

聚合体现的是一种整体与部分的关系。正是因为有这样的关系，在操作整体的时候，整体就封装了对部

分的操作。但并非所有对象间的关系都有整体与部分的关系，而那些不是整体与部分的关系是不能设计

成聚合的。因此，正确地识别聚合关系就变得尤为重要。

所谓的整体与部分的关系，就是当整体不存在时，部分就变得没有了意义。部分是整体的一个部分，与

整体有相同的生命周期。比如，只有创建了这张订单，才能创建它的订单明细；如果没有了这张订单，

那么它的订单明细就变得没有意义，就需要同时删除掉。这样的关系才具备整体与部分的关系，才是聚

合。

譬如：订单与用户之间的关系就不是聚合。因为用户不是创建订单时才存在的，而是在创建订单时早就

存在了；当删除订单时，用户不会随着订单的删除而删除，因为删除了订单，用户依然还是那个用户。

那么，饭店和菜单的关系是不是聚合关系呢？关键要看系统如何设计。如果系统设计成每个饭店都有各

不相同的菜单，每个菜单都是隶属于某个饭店，则饭店和菜单是聚合关系。这种设计让各个饭店都有

“宫保鸡丁”，但每个饭店都是各自不同的“宫保鸡丁”，比如在描述、或价格上的不同，甚至在数据

库中也是有各不相同的记录。这时，要查询菜单就要先查询饭店，离开了饭店的菜单是没有意义的。

但是，饭店和菜单还可以有另外一种设计思路，那就是所有的菜单都是公用的，去每个饭店只是选择有

还是没有这个菜品。这时，系统中有一个菜单对象，“宫保鸡丁”只是这个对象中的一条记录，其他各个

饭店，如果他们的菜单上有“宫保鸡丁”，则去这个对象，否则不。这时，菜单就不再