领域驱动设计：领域接口化设计

领域接口化设计

 　　把服务对象（service）和资源库对象（repository）设计成接口是最常见的。但是这对接口化的认识还远远不够，我们需要更深入地去分析接口化设计和更全面地应用接口化编程。所以我们要讨论的是全面接口化，尤其是对领域模型接口化的认识。

领域接口化

通常的情况下我们会把领域模型设计成类（class），但是你有没有想过把领域模型设计成接口（interface）？比如：

public interface User {    // ...}
public class UserImpl implements User {    // ...}

这样的设计似乎没有任何价值，那么继续深入地看看。比如：

这时候看起来有点东西，因为我们为了适配不同的数据源，提供了不同的实现类。最开始要把领域对象设计成接口，确实是为了在不同的 ORM 框架之间实现无缝切换。因为 JPA 对面向对象的支持最好，而 Mybatis 因为简单在大环境下比较流行。在解决这个问题时，通常使用层内包裹或者叫对象转换的方式来解决。具体来说是在持久层使用持久化对象（PO）与领域对象（DO）的之间进行转换。例如：

public class JpaUserRepository implements UserRepository {    // ...    @Override    public Optional<User> findById(String id) {        UserPO userPO = this.entityManager.find(UserPO.class, id);        return Optional.ofNullable(userPO).map(UserPO::toUser);    }
    @Override    public User save(User user) {        UserPO userPO = this.entityManager.find(UserPO.class, user.getId());        userPO.setNickname(user.getNickname());        // ...        return this.entityManager.merge(userPO).toUser();    }}

其中 UserPO 对象基本上是对数据库表的映射，然后将数据与 User 对象进行交换。对于这种需要交换的方式既有性能的损失又比较繁琐，将 User 设计成接口后，这个交换的问题就比较简单地解决了，如下：

public class JpaUserRepository implements UserRepository {    // ...    @Override    public User create(String id) {        return new JpaUser(id);    }
    @Override    public Optional<User> findById(String id) {        JpaUser user = this.entityManager.find(JpaUser.class, id);        return Optional.ofNullable(user);    }
    @Override    public User save(User user) {        JpaUser target = JpaUser.of(user);        return this.entityManager.merge(target);    }    // ...}

补充 JpaUser.of() 方法的实现：

public class JpaUser extends UserSupport {    // ...    public static JpaUser of(User user) {        if (user instanceof JpaUser) {            return (JpaUser) user;        }        var target = new JpaUser();        BeanUtils.copyProperties(user, target);        // ...        return target;    }}

对于使用 JPA 或者 Elasticsearch 等等各种不同的数据源，Spring data 都为此做了全面的支持。但由于 User 是接口，Spring data 提供的 Repository 接口泛型只支持具体类型，比如：

public interface ElasticsearchUserRepository        extends ElasticsearchRepository<ElasticsearchUser, String> {     // extends ElasticsearchRepository<User, String> // Not supported}

为了解决这个问题，我们需要使用委托的方式，如下：

public class DelegatingElasticsearchUserRepository implements UserRepository {
    private final ElasticsearchUserRepository elasticsearchUserRepository;
    public DelegatingElasticsearchUserRepository(ElasticsearchUserRepository elasticsearchUserRepository) {        this.elasticsearchUserRepository = elasticsearchUserRepository;    }
    @Override    public User create(String id) {        return new ElasticsearchUser(id);    }
    @Override    public Optional<User> findById(String id) {        return CastUtils.cast(this.elasticsearchUserRepository.findById(id));    }
    @Override    public User save(User user) {        return this.elasticsearchUserRepository.save(ElasticsearchUser.of(user));    }    // ...}

关联接口化

接口之间的关联关系依然需要具体到子类的关联关系上来讨论。对于需要持久化的实体来说，我们不可能直接在成员属性上使用接口类型，因为持久化框架无法通过接口来判定具体实现类。如下：

@Getter@Setter@NoArgsConstructor@Entity@Table(name = "mf_order")public class JpaOrder implements Order {    // ...    // OrderItem 是一个接口类型，不能持久化。    private List<OrderItem> items = new ArrayList<>();    // ...}

对于泛化关联关系问题，我们可以使用 JPA 注解提供的 targetEntity 属性来解决：

// ...public class JpaOrder implements Order {    // ...    // 通过指定具体的 targetEntity 类型，来解决泛化与特化的问题。    @OneToMany(targetEntity = JpaOrderItem.class)    private List<OrderItem> items = new ArrayList<>();    // ...}

• 支持 targetEntity 属性的注解包括：@OneToMany、@OneToOne、@ManyToOne、@ManyToMany。

对于不支持类似 targetEntity 属性的框架或者其它持久化技术，我们可以使用封装来解决。如下：

@Getter@Setter@NoArgsConstructor@Document(indexName = "user")public class ElasticsearchOrder implements Order {    // ...    // 使用具体特化类型进行解决。    private List<ElasticsearchOrderItem> items = new ArrayList<>();    @Override    public void setItems(List<OrderItem> items) {        this.items = Objects.requireNonNullElseGet(items, (Supplier<List<OrderItem>>) ArrayList::new)                .stream().map(ElasticsearchOrderItem::of).collect(Collectors.toList());    }    // ...}

如果使用的是 Mybatis 作为持久化框架，依然可以在 OrderMapper.xml 中进行配置来解决：

<resultMap id="Order" type="org.mallfoundry.order.repository.mybatis.MybatisOrder">    <!-- ... -->    <collection property="items" ofType="org.mallfoundry.order.repository.mybatis.MybatisOrderItem">        <!-- ... -->    </collection>    <!-- ... --></resultMap>

在解决掉不同数据源无缝切换和关联关系特化的问题后，在创建 User 对象上就和以往使用 new 的方式有所不同了，如下：

@Testpublic void testCreateUser() {    User user = this.userService.createUser(null); // new User()    user.setNickname("Nickname");    user.setGender(Gender.MALE);    this.userService.addUser(user);}

再过去创建对象都是使用 new 关键字，然而现在要使用 UserService 提供的 createUser(String id) 来创建。这种思维的转变可能让你初次不太很适应，但在考虑另一个问题。

系统接口化

对于一个产品我们要考虑的不只是产品本身能解决的业务需求，还需要在部署上有所追求。如果项目初期的并发量很小，客户可能采用单进程的方式部署，慢慢地单进程扛不住了会升级到集群的方式，最终还要升级到微服务的方式。如何在单进程、集群和微服务之间进行无缝切换呢？

再过去单机和集群项目与微服务项目是不能兼容的，因为领域模型都是类（class）而不是接口（interface）。具体来说：服务提供者（provider）的 User 对象与服务消费者（Consumer）的 User 对象是不兼容，不兼容将导致在单机项目中使用的是服务提供方的内部 User 对象，而一旦迁移到微服务项目后，需要大量的修改工作。要把以前调用方使用内部 User 对象替换为服务消费者提供的 User 对象。这样的工作也是不可以逆的，一旦迁移成功就不能降级到单机环境了。再过去我们确实把服务（service）设计成了接口，这种接口的设计对于内部的开发看似会有帮助，但是从实战的经验来看却不像大家想象的那样可以为 Service 提供不同的实现。因为现在都是迭代开发，都是一个版本一个版本的去不断完善应用服务代码，而不是替换应用服务代码，所以在 IDDD 中把应用服务（Application Service）类型由接口（Interface）改为了类（Class）。如果我们把领域对象设计成接口类型，并与服务接口以及其它接口一起组织在一个新的模块内，形成一个新的接口（API）模块。然后为各种不同地端口提供适配此端口的实现，这样的设计是不是可以解决在运行环境中无缝切换的问题，如下：

这样的设计使得调用者只需要使用 User 接口（user-api）开发业务，并且在单进程（Standalone）环境中只需要依赖 user 模块，在微服务环境中只需要依赖 user-openfeign-client 模块，在外部环境中只需要依赖 user-rest-client 模块。调用者通过依赖不同地实现模块来解决不同环境的无缝切换，并且调用者使用的代码是不需要改变的。