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 對象基本上是對數(shù)據(jù)庫表的映射，然后將數(shù)據(jù)與 User 對象進行交換雀费。對于這種需要交換的方式既有性能的損失又比較繁瑣干奢，將 User 設(shè)計成接口后，這個交換的問題就比較簡單地解決了盏袄，如下：

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() 方法的實現(xiàn)：

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 等等各種不同的數(shù)據(jù)源忿峻，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));
    }
    // ...
}

關(guān)聯(lián)接口化

order-association

接口之間的關(guān)聯(lián)關(guān)系依然需要具體到子類的關(guān)聯(lián)關(guān)系上來討論绰寞。

對于需要持久化的實體來說，我們不可能直接在成員屬性上使用接口類型酌毡，因為持久化框架無法通過接口來判定具體實現(xiàn)類克握。如下：

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

對于泛化關(guān)聯(lián)關(guān)系問題，我們可以使用 JPA 注解提供的 targetEntity 屬性來解決：

// ...
public class JpaOrder implements Order {
    // ...
    // 通過指定具體的 targetEntity 類型掰曾，來解決泛化與特化的問題旭蠕。
    @OneToMany(targetEntity = JpaOrderItem.class)
    private List<OrderItem> items = new ArrayList<>();
    // ...
}

• 支持 targetEntity 屬性的注解包括：@OneToMany、@OneToOne、@ManyToOne掏熬、@ManyToMany佑稠。

對于不支持類似 targetEntity 屬性的框架或者其它持久化技術(shù)，我們可以使用封裝來解決旗芬。如下：

@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>

在解決掉不同數(shù)據(jù)源無縫切換和關(guān)聯(lián)關(guān)系特化的問題后疮丛，在創(chuàng)建 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);
}

再過去創(chuàng)建對象都是使用 new 關(guān)鍵字，然而現(xiàn)在要使用 UserService 提供的 createUser(String id) 來創(chuàng)建誊薄。

這種思維的轉(zhuǎn)變可能讓你初次不太很適應(yīng)履恩，但在考慮另一個問題。

系統(tǒng)接口化

對于一個產(chǎn)品我們要考慮的不只是產(chǎn)品本身能解決的業(yè)務(wù)需求呢蔫，還需要在部署上有所追求切心。如果項目初期的并發(fā)量很小，客戶可能采用單進程的方式部署片吊，慢慢地單進程扛不住了會升級到集群的方式绽昏，最終還要升級到微服務(wù)的方式。如何在單進程俏脊、集群和微服務(wù)之間進行無縫切換呢而涉？

再過去單機和集群項目與微服務(wù)項目是不能兼容的，因為領(lǐng)域模型都是類（class）而不是接口（interface）联予。具體來說：服務(wù)提供者（provider）的 User 對象與服務(wù)消費者（Consumer）的 User 對象是不兼容啼县，不兼容將導(dǎo)致在單機項目中使用的是服務(wù)提供方的內(nèi)部 User 對象，而一旦遷移到微服務(wù)項目后沸久，需要大量的修改工作季眷。要把以前調(diào)用方使用內(nèi)部 User 對象替換為服務(wù)消費者提供的 User 對象。這樣的工作也是不可以逆的卷胯，一旦遷移成功就不能降級到單機環(huán)境了子刮。

再過去我們確實把服務(wù)（service）設(shè)計成了接口验辞，這種接口的設(shè)計對于內(nèi)部的開發(fā)看似會有幫助篷帅，但是從實戰(zhàn)的經(jīng)驗來看卻不像大家想象的那樣可以為 Service 提供不同的實現(xiàn)。因為現(xiàn)在都是迭代開發(fā)鼻由，都是一個版本一個版本的去不斷完善應(yīng)用服務(wù)代碼担钮，而不是替換應(yīng)用服務(wù)代碼橱赠，所以在 IDDD 中把應(yīng)用服務(wù)（Application Service）類型由接口（Interface）改為了類（Class）。

如果我們把領(lǐng)域?qū)ο笤O(shè)計成接口類型箫津，并與服務(wù)接口以及其它接口一起組織在一個新的模塊內(nèi)狭姨，形成一個新的接口（API）模塊宰啦。然后為各種不同地端口提供適配此端口的實現(xiàn)，這樣的設(shè)計是不是可以解決在運行環(huán)境中無縫切換的問題饼拍，如下：

user-modules

這樣的設(shè)計使得調(diào)用者只需要使用 User 接口（user-api）開發(fā)業(yè)務(wù)赡模，并且在單進程（Standalone）環(huán)境中只需要依賴 user 模塊，在微服務(wù)環(huán)境中只需要依賴 user-openfeign-client 模塊师抄，在外部環(huán)境中只需要依賴 user-rest-client 模塊漓柑。調(diào)用者通過依賴不同地實現(xiàn)模塊來解決不同環(huán)境的無縫切換，并且調(diào)用者使用的代碼是不需要改變的叨吮。

開源電商

Mallfoundry 是一個完全開源的使用 Spring Boot 開發(fā)的多商戶電商平臺欺缘。它可以嵌入到已有的 Java 程序中，或者作為服務(wù)器挤安、集群谚殊、云中的服務(wù)運行。

• 領(lǐng)域模型采用領(lǐng)域驅(qū)動設(shè)計（DDD）蛤铜、接口化以及面向?qū)ο笤O(shè)計嫩絮。

項目地址：https://gitee.com/mallfoundry/mall

總結(jié)

領(lǐng)域?qū)ο蠼涌诨沟梦覀冊趦?nèi)部實現(xiàn)了一套統(tǒng)一的接口，并將領(lǐng)域?qū)ο蠼涌诨瘮U展到系統(tǒng)級別時围肥，我們又在系統(tǒng)層次上設(shè)計出一套統(tǒng)一地全局接口來開發(fā)業(yè)務(wù)和應(yīng)對未來變化的環(huán)境剿干。這樣的設(shè)計雖然非常好，但對軟件設(shè)計人員穆刻、軟件架構(gòu)師以及開發(fā)人員的專業(yè)性也有了一定的要求置尔，但是它所帶來的好處是可見的。