@H_
403_0@笔者先前参与了一个有关汽车信息的网站开发，用于
显示不同品牌的汽车的信息，
包括车型，发动机型号，车身尺寸和汽车报价等信息。在建模时，我们只需要创建名为Car的实体（Entity）对象。其他的信息，比如车身尺寸，都是对Car起描述作用的，因此应该建模成值对象（Value Object）。
@H_
403_0@此时创建的Car对象如下：
@H_
403_0@public class Car {
@H_
403_0@private String id;
@H_
403_0@private CarType type;
@H_
403_0@private EngineType engineType;
@H_
403_0@private String brand;
@H_
403_0@private double length;
@H_
403_0@private double height;
@H_
403_0@private double width;
@H_
403_0@private int price;
@H_
403_0@}
@H_
403_0@对应的CarRepository为：
@H_
403_0@public interface CarRepository {
@H_
403_0@List<Car> getAllCars();
@H_
403_0@Car getCarById(String id);
@H_
403_0@}
@H_
403_0@现在新的需求来了：对于有些品牌的汽车，该网站与这些品牌的汽车经销商建立了合作关系，使得
用户在网站上点击一个
链接便可以进入对应的汽车经销商网站。
用户每点击一次
链接，汽车经销商都会给该网站相应的提成，这也成为了该网站的收入来源之一。该网站因此做出预测，在将来还会有更多这样的定制化需求，即针对不同的品牌
显示不同的
内容。
@H_
403_0@
（一）错误的建模方法
@H_
403_0@该网站的开发者立刻决定：可以将这些定制化需求建模成对象，名为Functionality，再在
数据库中存放这些Functionality和品牌（Brand）之间关联关系。比如现在有两种类型的定制化需求，一种即为上面讲到的是否
显示经销商
链接，另一种即为是否
显示报价。因此，他们建立了以下
数据库表：
@H_
403_0@Functionality BrandsShow
@H_
403_0@AgencyLink BMW,HONDAShowPriceTOYOTA,VOLVO,HONDA
@H_
403_0@相应地，他们创建了一个名为FuncitonalityEnablement的类与上表对应：
@H_
403_0@public class FunctionalityEnablement {
@H_
403_0@ private Functionality functionality;
@H_
403_0@ private String brands;
@H_
403_0@}
@H_
403_0@请注意，这里使用了一个String来包含多个Brand。要看某个品牌的汽车是否具有某个Functionality，可以通过以下Service类来完成：
@H_
403_0@public interface BrandFunctionalityService {
@H_
403_0@ boolean isFunctionalityEnabled(Functionality functionality,String brand);
@H_
403_0@}
@H_
403_0@该BrandFuntionalityService先通过DAO层
获取到某中Functionality在
数据库中所对应的FunctionalityEnablement，再
调用isFunctionalityEnabled()
方法，传入Brand值，检查该Brand是否拥有该Functionality，即检查该Brand是否包含在FunctionalityEnablement中的brands中。
@H_
403_0@对于以上建模方式，我至少可以看到两处不足之处：
@H_
403_0@（1）判断某个Brand是否拥有某种Functionality更应该是Brand本身的一种行为，而不是通过Service来完成。
@H_
403_0@（2）在有了新的需求之后，不同的Functionality对Brand起到了描述作用，并且这些描述信息有可能随着时间改变，比如在之后某个时刻，该网站又与BUICK品牌的经销商建立的合作关系。这样一来，Brand不再是值对象了，而是变成了具有生命周期的实体对象。但是以上的
解决方案依然将Brand作为值对象来使用，并且将本应该成为描述信息的Functionality当成了实体来使用，的确不应该。
@H_
403_0@
（二）正确的建模方法——采用领域驱动设计（DDD）
@H_
403_0@在使用领域驱动设计时，我们实际上可以建立两个限界上下文（Bounded Context），一个为汽车目录上下文（Car Category Context），另一个为品牌
功能上下文（Brand Functionality Context）。在有些情况下，不同的上下文运行在不同的进程空间中，但是对于本文中的情况，由于两个上下文联系密切，又相对较小，我们可以通过引入不同的Java包来划分这两个限界上下文。
@H_
403_0@这样一来，在汽车目录上下文中，Brand依然可以建模成值对象，但是在品牌
功能上下文中，Brand则应该建模成实体对象并且进行持久化。汽车目录上下文将作为品牌
功能上下文的下游，即依赖于品牌
功能上下文。在汽车目录上下文中，如果需要查看某个品牌是否拥有某种
功能，我们可以
调用品牌
功能上下文所提供的应用服务（Application Service）。应用服务是非常薄的一层，限界上下文的领域模型便通过该层向外界提供基于用例的服务。
@H_
403_0@这里我们将重点放在品牌
功能上下文上。通过以上讨论，我们知道，Brand应该为实体对象，并且拥有一种或多种Functionality，为了不至产生混淆，我们将实体类型的Brand命名为ConfigurableBrand。该ConfigurableBrand定义如下：
@H_
403_0@public class ConfigurableBrand {
@H_
403_0@ private String name;
@H_
403_0@ private List<Functionality> functionalities;
@H_
403_0@ publicboolean hasFunctionality(Functionality functionality) {
@H_
403_0@ return functionalities.contains(functionality);
@H_
403_0@ }
@H_
403_0@}
@H_
403_0@对应的ConfigurableBrandRepository为：
@H_
403_0@public interface ConfigurableBrandRepository {
@H_
403_0@ public List<ConfigurableBrand> getAllConfigurableBrands();
@H_
403_0@ public ConfigurableBrand getConfigurableBrandByName(String name);
@H_
403_0@}
@H_
403_0@在持久化ConfigurableBrand时，我们可以像上文中那样，在不完全遵循关系型
数据库范式的情况下对其进行持久化，此时是将ConfigurableBrand的name作为主键，其他信息（这里只有Functionality）则序列化到一个列中：
@H_
403_0@BrandName Funcionalities
@H_
403_0@BMW ShowAgencyLink
@H_
403_0@TOYOTA ShowPrice
@H_
403_0@HONDA ShowAgencyLink,ShowPrice
@H_
403_0@VOLVO ShowPrice
@H_
403_0@当然，如果你习惯了遵循
数据库范式，那么你也可以建立3张
数据库表，一张用于存放ConfigurableBrand，一张用于存放Functionality，另一张关联表存放前两者之间的关联关系。此时，ConfigurableBrand和Functionality存在着多对多的关系。
@H_
403_0@品牌
功能上下文的应用服务提供了以下业务
方法：
@H_
403_0@public interface ConfigurableBrandFunctionalityService {
@H_
403_0@ boolean isFunctionalityEnabled(String functionality,String brand);
@H_
403_0@}
@H_
403_0@当汽车目录上下文需要知道某个品牌是否拥有某种
功能时，它便应该
调用品牌
功能上下文的应用服务ConfigurableBrandFunctionalityService，该Service首先通过ConfigurableBrandRepository找到相应的ConfigurableBrand实体对象，再
调用ConfigurableBrand中的hasFunctionality()
方法以判断该ConfigurableBrand是否拥有某种Functionality。
@H_
403_0@对于ConfigurableBrandFunctionalityService，我们需要注意，首先外界上下文如果需要访问品牌
功能上下文，它必须通过ConfigurableBrandFunctionalityService应用服务，再由该应用服务委派给品牌
功能的领域模型，即应用服务才是领域模型的直接客户。另外，在
调用ConfigurableBrandFunctionalityService时，我们并没有传入ConfigurableBrand和Functionality领域对象，而是直接使用了String类型，这也是合理的，因为外界不应该直接访问品牌
功能上下文中的领域模型，而是应该通过应用服务。再者，在上文中我们讲到，isFunctionalityEnabled()
方法更应该建模在ConfigurableBrand实体上，但是这里我们依然将其放在了ConfigurableBrandFunctionalityService上。原因在于，判断一个品牌是否拥有某种
功能的核心业务逻辑的确是放在ConfigurableBrand中的，即hasFunctionality()
方法，而ConfigurableBrandFunctionalityService中的isFunctionalityEnabled()
方法只是反应了一个业务用例，它本身并不处理业务逻辑，而是将逻辑委派给领域模型ConfigurableBrand。
