領(lǐng)域驅(qū)動設(shè)計(jì)（DDD）：領(lǐng)域接口化設(shè)計(jì)
來源：juejin.cn/post/6894109393173315597
領(lǐng)域接口化設(shè)計(jì)
把服務(wù)對象（service）和資源庫對象（repository）設(shè)計(jì)成接口是最常見的。但是這對接口化的認(rèn)識還遠(yuǎn)遠(yuǎn)不夠，我們需要更深入地去分析接口化設(shè)計(jì)和更全面地應(yīng)用接口化編程。所以我們要討論的是全面接口化，尤其是對領(lǐng)域模型 接口化的認(rèn)識。
領(lǐng)域接口化
通常的情況下我們會把領(lǐng)域模型設(shè)計(jì)成類（class） ，但是你有沒有想過把領(lǐng)域模型設(shè)計(jì)成接口（interface） ？比如：
public interface User {
// ...
}
public class UserImpl implements User {
// ...
}
這樣的設(shè)計(jì)似乎沒有任何價(jià)值，那么繼續(xù)深入地看看。比如：
user-object-uml
這時(shí)候看起來有點(diǎn)東西，因?yàn)槲覀優(yōu)榱诉m配不同的數(shù)據(jù)源 ，提供了不同的實(shí)現(xiàn)類。
最開始要把領(lǐng)域?qū)ο?/strong> 設(shè)計(jì)成接口，確實(shí)是為了在不同的 ORM 框架之間實(shí)現(xiàn)無縫切換 。因?yàn)?JPA 對面向?qū)ο蟮闹С肿詈茫?Mybatis 因?yàn)楹唵卧诖蟓h(huán)境下比較流行。在解決這個(gè)問題時(shí)，通常使用層內(nèi)包裹 或者叫對象轉(zhuǎn)換 的方式來解決。具體來說是在持久層使用持久化對象（PO）與領(lǐng)域?qū)ο螅―O）的之間進(jìn)行轉(zhuǎn)換。例如：
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 對象進(jìn)行交換。對于這種需要交換的方式既有性能的損失又比較繁瑣，將 User 設(shè)計(jì)成接口后，這個(gè)交換的問題就比較簡單地解決了，如下：
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);
}
// ...
}
補(bǔ)充 JpaUser.of() 方法的實(shí)現(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
}
為了解決這個(gè)問題，我們需要使用委托的方式，如下：
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)系上來討論。
對于需要持久化的實(shí)體來說，我們不可能直接在成員屬性上使用接口類型，因?yàn)槌志没蚣軣o法通過接口來判定具體實(shí)現(xiàn)類。如下：
@Getter
@Setter
@NoArgsConstructor
@Entity
@Table(name = "mf_order")
public class JpaOrder implements Order {
// ...
// OrderItem 是一個(gè)接口類型，不能持久化。
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 {
// ...
// 使用具體特化類型進(jìn)行解決。
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 中進(jìn)行配置來解決：
<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)，但在考慮另一個(gè)問題。
系統(tǒng)接口化
對于一個(gè)產(chǎn)品我們要考慮的不只是產(chǎn)品本身能解決的業(yè)務(wù)需求，還需要在部署上有所追求。如果項(xiàng)目初期的并發(fā)量很小，客戶可能采用單進(jìn)程的方式部署，慢慢地單進(jìn)程扛不住了會升級到集群的方式，最終還要升級到微服務(wù)的方式。如何在單進(jìn)程、集群和微服務(wù)之間進(jìn)行無縫切換呢？
再過去單機(jī)和集群項(xiàng)目與微服務(wù)項(xiàng)目是不能兼容的，因?yàn)轭I(lǐng)域模型都是類（class）而不是接口（interface）。具體來說：服務(wù)提供者（provider）的 User 對象與服務(wù)消費(fèi)者（Consumer）的 User 對象是不兼容，不兼容將導(dǎo)致在單機(jī)項(xiàng)目中使用的是服務(wù)提供方的內(nèi)部 User 對象，而一旦遷移到微服務(wù)項(xiàng)目后，需要大量的修改工作。要把以前調(diào)用方使用內(nèi)部 User 對象替換為服務(wù)消費(fèi)者提供的 User 對象。這樣的工作也是不可以逆的，一旦遷移成功就不能降級到單機(jī)環(huán)境了。
再過去我們確實(shí)把服務(wù)（service）設(shè)計(jì)成了接口，這種接口的設(shè)計(jì)對于內(nèi)部的開發(fā)看似會有幫助，但是從實(shí)戰(zhàn)的經(jīng)驗(yàn)來看卻不像大家想象的那樣可以為 Service 提供不同的實(shí)現(xiàn)。因?yàn)楝F(xiàn)在都是迭代開發(fā)，都是一個(gè)版本一個(gè)版本的去不斷完善應(yīng)用服務(wù)代碼，而不是替換應(yīng)用服務(wù)代碼，所以在 IDDD 中把應(yīng)用服務(wù)（Application Service）類型由接口（Interface）改為了類（Class）。
如果我們把領(lǐng)域?qū)ο笤O(shè)計(jì)成接口類型，并與服務(wù)接口以及其它接口一起組織在一個(gè)新的模塊內(nèi)，形成一個(gè)新的接口（API）模塊。然后為各種不同地端口提供適配此端口的實(shí)現(xiàn)，這樣的設(shè)計(jì)是不是可以解決在運(yùn)行環(huán)境中無縫切換的問題，如下：
user-modules
這樣的設(shè)計(jì)使得調(diào)用者 只需要使用 User 接口（user-api）開發(fā)業(yè)務(wù)，并且在單進(jìn)程（Standalone）環(huán)境中只需要依賴 user 模塊，在微服務(wù)環(huán)境中只需要依賴 user-openfeign-client 模塊，在外部環(huán)境中只需要依賴 user-rest-client 模塊。調(diào)用者通過依賴不同地實(shí)現(xiàn)模塊 來解決不同環(huán)境的無縫切換，并且調(diào)用者使用的代碼是不需要改變的。
開源電商
Mallfoundry 是一個(gè)完全開源的使用 Spring Boot 開發(fā)的多商戶電商平臺。它可以嵌入到已有的 Java 程序中，或者作為服務(wù)器、集群、云中的服務(wù)運(yùn)行。
領(lǐng)域模型采用領(lǐng)域驅(qū)動設(shè)計(jì)（DDD）、接口化以及面向?qū)ο笤O(shè)計(jì)。
項(xiàng)目地址：https://gitee.com/mallfoundry/mall
總結(jié)
領(lǐng)域?qū)ο蠼涌诨沟梦覀冊趦?nèi)部實(shí)現(xiàn)了一套統(tǒng)一的接口，并將領(lǐng)域?qū)ο蠼涌诨瘮U(kuò)展到系統(tǒng)級別時(shí)，我們又在系統(tǒng)層次上設(shè)計(jì)出一套統(tǒng)一地全局接口來開發(fā)業(yè)務(wù)和應(yīng)對未來變化的環(huán)境。這樣的設(shè)計(jì)雖然非常好，但對軟件設(shè)計(jì)人員、軟件架構(gòu)師以及開發(fā)人員的專業(yè)性也有了一定的要求，但是它所帶來的好處是可見的。
最近面試BAT，整理一份面試資料《Java面試BATJ通關(guān)手冊》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫、數(shù)據(jù)結(jié)構(gòu)等等。
獲取方式：點(diǎn)“在看”，關(guān)注公眾號并回復(fù) Java 領(lǐng)取，更多內(nèi)容陸續(xù)奉上。
文章有幫助的話，在看，轉(zhuǎn)發(fā)吧。
謝謝支持喲 (*^__^*)
