?[[357638]]?

本文轉(zhuǎn)載自微信公眾號「codeasy」，作者閻華。轉(zhuǎn)載本文請聯(lián)系codeasy公眾號。 

用UOW模式實現(xiàn)Repository

看了《無法實施富領域模型的罪魁禍首找到了》這一篇文章后，很多人都會問這種Repository是這么實現(xiàn)的。這種Repository的實現(xiàn)背后用了一個叫做 “Unit of Work (UOW)”的模式：

Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.Unit of Work --Martin Fowler

UOW模式是在業(yè)務用例的操作中跟蹤對象的所有更改(增加、刪除和更新)，并將所有更改的對象保存在一個列表中。在業(yè)務用例的終點，通過事務，一次性提交所有更改，以確保數(shù)據(jù)的完整性和有效性?？偠灾?，UOW協(xié)調(diào)這些對象的持久化及并發(fā)問題。

??

很多實現(xiàn)了UOW模式的框架都采用了保存快照的方式來跟蹤對象狀態(tài)的變化，如上圖所示，通過對比開始時對象的狀態(tài)和編輯后的對象的狀態(tài)，從而決定如何更新數(shù)據(jù)庫。這樣做的好處是可以增量按需更新。

重點是最后一次性保存變更，跟蹤對象狀態(tài)的變更不是必須的，我們看看IDDD_Sample是怎么實現(xiàn)的。

IDDD_Sample使用了LevelDB來存儲數(shù)據(jù)，以 agilepm.port.adapter.persistence.LevelDBSprintRepository 為例：

void save(Sprint aSprint, LevelDBUnitOfWork aUoW) {
LevelDBKey primaryKey = new LevelDBKey(PRIMARY, aSprint.tenantId().id(), aSprint.sprintId().id());
aUoW.write(primaryKey, aSprint);
}

其中 LevelDBUnitOfWork 的write方法是這么實現(xiàn)的：

public void write(LevelDBKey aKey, Object aValue) {
String serializedValue = this.serializer.serialize(aValue);
this.batch.put(aKey.keyAsBytes(), serializedValue.getBytes());
}

它把整個聚合序列化后存儲了。由于沒有跟蹤對象變更，所以也無法實現(xiàn)增量的更新，只能粗暴地用最新的聚合序列化后完全覆蓋之前的聚合存儲了。 但這種方式對我們大部分場景參考性不大，一個原因是我們最常用的還是關系型數(shù)據(jù)庫， 另一個原因是這種非增量的更新開銷還是比較大的。

合適的就是最好的，我有個朋友曾用MongoDB作存儲，使用了這樣的模式，效果很好，他所做的那個應用數(shù)據(jù)量不大，并發(fā)不高，用這種方式大大節(jié)約了開發(fā)和維護的成本。

那我們看看當使用關系型數(shù)據(jù)庫的時候有什么框架可以選擇。

使用JPA實現(xiàn)Repository

JPA (Java Persistence API) 是一個Java 持久化規(guī)范，最流行的一個實現(xiàn)是Hibernate，它可以大大簡化對數(shù)據(jù)庫的操作，然而，JPA在國內(nèi)不受待見：

然而要實現(xiàn)UOW模式的Repository，使用JPA依然是最佳選擇，你幾乎不用自己做任何的工作，只要把聚合中的對象和表映射好就可以了。

JPA/Hibernate還提供了易用的樂觀鎖功能，在聚合根上維護一個樂觀鎖非常簡單

JPA/Hibernate在國內(nèi)不受待見的一個重要原因，不是它不好用，而是太好用了——隱藏了很多實現(xiàn)細節(jié)有時候顯得不太靈活，提供了太多的高級功能用不好容易踩坑。

所以，使用JPA，請遵循以下幾點建議：

• 只用它的功能的一個子集，比如要禁用Many-to-Many映射、禁用延遲加載的功能等;
• 還記得之前關于CQRS這篇文章吧，很多查詢場景不需要聚合內(nèi)的全部數(shù)據(jù)，所以，有些Query的實現(xiàn)，你完全可以不使用JPA，而是用原始的SQL去查，比如用JDBC或MyBatis;理解了CQRS，這些技術(shù)是可以很好地結(jié)合在一起使用的;
• 確定你的聚合中的數(shù)據(jù)不需要分庫分表。即使你使用了Proxy模式的分庫分表中間件，使用JPA還是有問題的，這個以后專門寫一篇文章說說為什么有問題，以及如何解決這個問題;

嫌棄JPA不夠精簡的人很多，以至于Spring的官方推出了 Spring-Data-JDBC，一個專門為DDD的聚合存儲設計的ORM框架，它比JPA輕量很多，簡單很多，然而，為了輕量簡單，它也沒有對對象狀態(tài)修改進行跟蹤，所以在保存聚合的時候無法像JPA一樣按需更新數(shù)據(jù)庫，而是如IDDD_Sample一樣，粗暴地覆蓋更新，甚至會先刪除聚合下所有子實體后再重新插入(無論子實體數(shù)據(jù)有沒有變更)，這可能會帶來不可控的性能問題。

如果我們又想用關系數(shù)據(jù)庫，又不能使用JPA，那還有別的辦法嗎?

自己寫代碼實現(xiàn)資源庫

前段時間我嘗試過一種方法：自己手寫Repository的實現(xiàn)，在聚合保存前，先從庫里load出來一個聚合，把這兩個聚合里的對象進行比較(diff)，找出差異，生成操作數(shù)據(jù)庫的SQL語句，去增量更新數(shù)據(jù)庫。

這樣做的問題是需要寫很多的Repository代碼，而且很容易出錯也不容易維護，我試圖做一些抽象來簡化代碼，最后發(fā)現(xiàn)抽象越多越像JPA了。

這樣做還有一個問題是需要在保存前額外加載一次，如果想避免這個問題，可以看看《DDD之聚合持久化應該怎么做?| https://zhuanlan.zhihu.com/p/334344752》，但這種方法還是沒有避免需要寫很多代碼的問題。

自己編碼實現(xiàn)的好處是可控，比如容易處理分庫分表的問題。但實現(xiàn)起來太復雜，編寫和維護成本高，也容易出問題，這大大打擊了使用富領域模型的熱情。

總之，實現(xiàn)Repository，還沒有一件稱手的家伙。

再次審視端口適配器模型

前面我們提到過DDD提倡的六邊形模型，即端口適配器模型，Repository就是一個例子。比如接口 agilepm.domain.model.product.sprint.SprintRepository 這是一個接口，即所謂的端口，它和領域?qū)ο笤谕粋€包里;而 agilepm.port.adapter.persistence.LevelDBSprintRepository這個實現(xiàn)是在另外的叫 adapter 的包下，這背后體現(xiàn)的是依賴倒置原則，這樣可以讓領域?qū)雍蛻脤硬灰蕾囉诰唧w的技術(shù)實現(xiàn)。

Repository的實現(xiàn)只是一種adapter，下一篇我們講一講如何訪問另一個上下文中的服務，那本質(zhì)上也是一種port/adapter，但有更多的不一樣的細節(jié)需要注意。