领域驱动设计（DDD）：领域接口化设计-技术圈

领域接口化设计
领域接口化
关联接口化
系统接口化
开源电商
总结

领域接口化设计

把服务对象（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 的方式有所不同了，如下：

@Test
public 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 模块。调用者通过依赖不同地实现模块 来解决不同环境的无缝切换，并且调用者使用的代码是不需要改变的。