一次领域驱动设计(DDD)的实际应用

前端之家收集整理的这篇文章主要介绍了一次领域驱动设计(DDD)的实际应用前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

笔者先前参与了一个有关汽车信息的网站开发,用于显示不同品牌的汽车的信息,包括车型,发动机型号,车身尺寸和汽车报价等信息。在建模时,我们只需要创建名为Car的实体(Entity)对象。其他的信息,比如车身尺寸,都是对Car起描述作用的,因此应该建模成值对象(Value Object)。

此时创建的Car对象如下:

public class Car {

private String id;

private CarType type;

private EngineType engineType;

private String brand;

private double length;

private double height;

private double width;

private int price;

}

对应的CarRepository为:

public interface CarRepository {

List<Car> getAllCars();

Car getCarById(String id);

}

现在新的需求来了:对于有些品牌的汽车,该网站与这些品牌的汽车经销商建立了合作关系,使得用户在网站上点击一个链接便可以进入对应的汽车经销商网站。用户每点击一次链接,汽车经销商都会给该网站相应的提成,这也成为了该网站的收入来源之一。该网站因此做出预测,在将来还会有更多这样的定制化需求,即针对不同的品牌显示不同的内容

(一)错误的建模方法

该网站的开发者立刻决定:可以将这些定制化需求建模成对象,名为Functionality,再在数据库中存放这些Functionality和品牌(Brand)之间关联关系。比如现在有两种类型的定制化需求,一种即为上面讲到的是否显示经销商链接,另一种即为是否显示报价。因此,他们建立了以下数据库表:

Functionality BrandsShow

AgencyLink BMW,HONDAShowPriceTOYOTA,VOLVO,HONDA

相应地,他们创建了一个名为FuncitonalityEnablement的类与上表对应:

public class FunctionalityEnablement {

private Functionality functionality;

private String brands;

}

请注意,这里使用了一个String来包含多个Brand。要看某个品牌的汽车是否具有某个Functionality,可以通过以下Service类来完成:

public interface BrandFunctionalityService {

boolean isFunctionalityEnabled(Functionality functionality,String brand);

}

该BrandFuntionalityService先通过DAO层获取到某中Functionality在数据库中所对应的FunctionalityEnablement,再调用isFunctionalityEnabled()方法,传入Brand值,检查该Brand是否拥有该Functionality,即检查该Brand是否包含在FunctionalityEnablement中的brands中。

对于以上建模方式,我至少可以看到两处不足之处:

(1)判断某个Brand是否拥有某种Functionality更应该是Brand本身的一种行为,而不是通过Service来完成。

(2)在有了新的需求之后,不同的Functionality对Brand起到了描述作用,并且这些描述信息有可能随着时间改变,比如在之后某个时刻,该网站又与BUICK品牌的经销商建立的合作关系。这样一来,Brand不再是值对象了,而是变成了具有生命周期的实体对象。但是以上的解决方案依然将Brand作为值对象来使用,并且将本应该成为描述信息的Functionality当成了实体来使用,的确不应该。

(二)正确的建模方法——采用领域驱动设计(DDD)

在使用领域驱动设计时,我们实际上可以建立两个限界上下文(Bounded Context),一个为汽车目录上下文(Car Category Context),另一个为品牌功能上下文(Brand Functionality Context)。在有些情况下,不同的上下文运行在不同的进程空间中,但是对于本文中的情况,由于两个上下文联系密切,又相对较小,我们可以通过引入不同的Java包来划分这两个限界上下文。

这样一来,在汽车目录上下文中,Brand依然可以建模成值对象,但是在品牌功能上下文中,Brand则应该建模成实体对象并且进行持久化。汽车目录上下文将作为品牌功能上下文的下游,即依赖于品牌功能上下文。在汽车目录上下文中,如果需要查看某个品牌是否拥有某种功能,我们可以调用品牌功能上下文所提供的应用服务(Application Service)。应用服务是非常薄的一层,限界上下文的领域模型便通过该层向外界提供基于用例的服务。

这里我们将重点放在品牌功能上下文上。通过以上讨论,我们知道,Brand应该为实体对象,并且拥有一种或多种Functionality,为了不至产生混淆,我们将实体类型的Brand命名为ConfigurableBrand。该ConfigurableBrand定义如下:

public class ConfigurableBrand {

private String name;

private List<Functionality> functionalities;

publicboolean hasFunctionality(Functionality functionality) {

return functionalities.contains(functionality);

}

}

对应的ConfigurableBrandRepository为:

public interface ConfigurableBrandRepository {

public List<ConfigurableBrand> getAllConfigurableBrands();

public ConfigurableBrand getConfigurableBrandByName(String name);

}

在持久化ConfigurableBrand时,我们可以像上文中那样,在不完全遵循关系型数据库范式的情况下对其进行持久化,此时是将ConfigurableBrand的name作为主键,其他信息(这里只有Functionality)则序列化到一个列中:

BrandName Funcionalities

BMW ShowAgencyLink

TOYOTA ShowPrice

HONDA ShowAgencyLink,ShowPrice

VOLVO ShowPrice

当然,如果你习惯了遵循数据库范式,那么你也可以建立3张数据库表,一张用于存放ConfigurableBrand,一张用于存放Functionality,另一张关联表存放前两者之间的关联关系。此时,ConfigurableBrand和Functionality存在着多对多的关系。

品牌功能上下文的应用服务提供了以下业务方法

public interface ConfigurableBrandFunctionalityService {

boolean isFunctionalityEnabled(String functionality,String brand);

}

当汽车目录上下文需要知道某个品牌是否拥有某种功能时,它便应该调用品牌功能上下文的应用服务ConfigurableBrandFunctionalityService,该Service首先通过ConfigurableBrandRepository找到相应的ConfigurableBrand实体对象,再调用ConfigurableBrand中的hasFunctionality()方法以判断该ConfigurableBrand是否拥有某种Functionality。

对于ConfigurableBrandFunctionalityService,我们需要注意,首先外界上下文如果需要访问品牌功能上下文,它必须通过ConfigurableBrandFunctionalityService应用服务,再由该应用服务委派给品牌功能的领域模型,即应用服务才是领域模型的直接客户。另外,在调用ConfigurableBrandFunctionalityService时,我们并没有传入ConfigurableBrand和Functionality领域对象,而是直接使用了String类型,这也是合理的,因为外界不应该直接访问品牌功能上下文中的领域模型,而是应该通过应用服务。再者,在上文中我们讲到,isFunctionalityEnabled()方法更应该建模在ConfigurableBrand实体上,但是这里我们依然将其放在了ConfigurableBrandFunctionalityService上。原因在于,判断一个品牌是否拥有某种功能的核心业务逻辑的确是放在ConfigurableBrand中的,即hasFunctionality()方法,而ConfigurableBrandFunctionalityService中的isFunctionalityEnabled()方法只是反应了一个业务用例,它本身并不处理业务逻辑,而是将逻辑委派给领域模型ConfigurableBrand。

猜你在找的设计模式相关文章