领域驱动设计（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）之间关联关系。比如现在有两种类型的定制化需求，一种即为上面讲到的是否显示经销商链接，另一种即为是否显示报价。因此，他们建立了以下数据库表：

相应地，他们创建了一个名为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;

    public boolean hasFunctionality(Functionality functionality) {
        return functionalities.contains(functionality);
    }
}

对应的ConfigurableBrandRepository为：

public interface ConfigurableBrandRepository {
    public List<ConfigurableBrand> getAllConfigurableBrands();

    public ConfigurableBrand getConfigurableBrandByName(String name);
}

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

当然，如果你习惯了遵循数据库范式，那么你也可以建立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。