[[355640]]

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

使用了DDD(領(lǐng)域驅(qū)動設(shè)計)后，代碼編寫有什么不一樣呢?這可能是程序員們在接觸DDD后最關(guān)心的一個問題。這個系列文章會對一些優(yōu)秀的DDD實例代碼進行分析，管中窺豹，略見數(shù)斑。這是第四篇，繼續(xù)以IDDD_Sample為例做分析。

今天我們說一下“讀”類型的應(yīng)用服務(wù)怎么設(shè)計，以及如何獲得更好的性能。

模型設(shè)計時不要考慮查詢

按DDD設(shè)計領(lǐng)域模型時，有兩個很有用的原則：

• 模型對展現(xiàn)技術(shù)要無感知，比如展現(xiàn)是用WEB，還是APP端，在做模型設(shè)計時不要考慮
• 不要關(guān)心復(fù)雜查詢和報表的需求

那這樣領(lǐng)域模型設(shè)計出來后，經(jīng)常受到的挑戰(zhàn)是查詢性能不好。相比于以數(shù)據(jù)為中心的設(shè)計思維，以領(lǐng)域?qū)ο鬄橹行牡脑O(shè)計思維設(shè)計出的數(shù)據(jù)存儲粒度更細，冗余更少，確實不利于查詢。

另外一個對查詢不友好的地方在于聚合這個概念。比如我想查一個訂單列表，列表中的每一行只需要訂單這個聚合根的數(shù)據(jù)，不需要把每一條訂單下的子實體都被查詢出來，那樣性能會很差。

可以使用JPA提供的懶加載來實現(xiàn)只加載聚合根，但是會帶來更多的其它的問題，懶加載已被認為是不被推薦使用的反模式。

大部分的業(yè)務(wù)系統(tǒng)都是讀多寫少，領(lǐng)域模型是重要，但能提供符合性能要求的查詢也很重要。DDD是怎么解決這個矛盾的呢?

模型對查詢不友好怎么辦

DDD推薦使用CQRS( Command Query Responsibility Segregation， 命令職責分離)這種模式來解決這個問題。

https://martinfowler.com/bliki/CQRS.html

我們來看看IDDD_Sample的 com.saasovation.collaboration.application.forum 下的應(yīng)用服務(wù)，這些服務(wù)分成了兩類：

image.png

一類是 ApplicationService 一類是 QueryService 。

ApplicationService里的方法我們上篇文章里見過了，方法的入?yún)⑹且粋€ Command 對象，返回值是一個 CommandResponse 對象。方法里通過 Repository 獲取聚合根，操作聚合根后，再通過 Repository 來持久化。這就是CQRS里的“C”，即命令(Command)，它會改變系統(tǒng)的狀態(tài)。

在collaboration這個上下文的實現(xiàn)里，沒有把入?yún)b成Command對象，可以參考agilepm上下文中ApplicationService的實現(xiàn)。IDDD_Sample為了演示各種風格，不同上下文的實現(xiàn)方式不太統(tǒng)一。也有人是把這種ApplicationService里的一個個方法變成一個個CommandHandler，可讀性更好，但本質(zhì)上是一樣的。

CQRS里的“Q”指的是Query，顧名思義，查詢不會改變系統(tǒng)狀態(tài)的。

那分離是什么意思呢?

最粗淺的理解是把這些查詢方法放到 QueryService 里，而不是放到ApplicationService 里。但這只是個表象。我們看一個Query方法是怎么寫的：

public ForumDiscussionsData forumDiscussionsDataOfId(String aTenantId, String aForumId) { 
        return this.queryObject( 
                ForumDiscussionsData.class, 
                "select " 
                +  "forum.closed, forum.creator_email_address, forum.creator_identity, " 
                +  "forum.creator_name, forum.description, forum.exclusive_owner, forum.forum_id, " 
                +  "forum.moderator_email_address, forum.moderator_identity, forum.moderator_name, " 
                +  "forum.subject, forum.tenant_id, " 
                +  "disc.author_email_address as o_discussions_author_email_address, " 
                +  "disc.author_identity as o_discussions_author_identity, " 
                +  "disc.author_name as o_discussions_author_name, " 
                +  "disc.closed as o_discussions_closed, " 
                +  "disc.discussion_id as o_discussions_discussion_id, " 
                +  "disc.exclusive_owner as o_discussions_exclusive_owner, " 
                +  "disc.forum_id as o_discussions_forum_id, " 
                +  "disc.subject as o_discussions_subject, " 
                +  "disc.tenant_id as o_discussions_tenant_id " 
                + "from tbl_vw_forum as forum left outer join tbl_vw_discussion as disc " 
                + " on forum.forum_id = disc.forum_id " 
                + "where (forum.tenant_id = ? and forum.forum_id = ?)", 
                new JoinOn("forum_id", "o_discussions_forum_id"), 
                aTenantId, 
                aForumId); 
    } 

來自 ForumQueryService

我們發(fā)現(xiàn)這個查詢服務(wù)里即沒有使用領(lǐng)域?qū)ο笠矝]使用 Repository ，甚至 join 的兩個表是代表兩個聚合根的數(shù)據(jù)!在Query方法里可以直接查詢數(shù)據(jù)庫去返回一個查詢顯示用的DTO，這可以看做是分離的第一個意思，即Query里可以不使用領(lǐng)域?qū)ο蠛? Repository 。

我覺得可以不使用，意味著也可以使用

第二個意思是數(shù)據(jù)存儲的分離。最簡單的方式是處理 Command 的 ApplicationService/CommandHandler 訪問的是主庫，而 QueryService 訪問的是從庫。

在復(fù)雜一點，ApplicationService 可以訪問MySQL，而 QueryService 可以訪問Elasticsearch這種NoSQL，這時候需要做數(shù)據(jù)的同步。觸發(fā)數(shù)據(jù)同步，可以監(jiān)聽領(lǐng)域事件來實現(xiàn)，也可以使用canal這種框架監(jiān)聽binlog來實現(xiàn)。除了專門為查詢而設(shè)計的NoSQL本身有更好的查詢性能，同時，我們在數(shù)據(jù)結(jié)構(gòu)設(shè)計上也可以專門為查詢來做優(yōu)化，比如把多個關(guān)聯(lián)聚合的數(shù)據(jù)放到一起。

image.png

其實，IDDD_Sample的例子中的 collaboration 這個上下文就是這么實現(xiàn)的——領(lǐng)域?qū)ο蟮拇鎯κ褂玫氖荓evelDB，查詢用的是MySQL。

這種方式我很多年前就看到一個團隊在用，他們也把Service分為WriteServcie和ReadService兩種，但是并沒有叫CQRS這個名字，也沒有總結(jié)為一種模式，而是憑著經(jīng)驗這么做了。

事件溯源和CQRS

和CQRS經(jīng)常一起出現(xiàn)的一種模式是事件溯源(Event Sourcing)。事件溯源是一種更“前衛(wèi)”的模式，它不存儲對象的狀態(tài)，相反，存儲影響其狀態(tài)的所有事件。

需要查詢對象的當前狀態(tài)時，只要把所有事件回放一遍就能得到。但是，這種回放太昂貴了，所以可以保留一份對象的最新快照，這就需要和CQRS模式結(jié)合。

image.png

IDDD_Sample例子中的 collaboration 這個上下文實際上使用的就是事件溯源。我們看它的 Repository 實現(xiàn)，存儲的是事件而不是實體本身：

事件溯源加上CQRS很“酷”，但一般不建議使用，實現(xiàn)的成本太高。

public class EventStoreForumRepository 
        extends EventStoreProvider 
        implements ForumRepository { 
 
    @Override 
    public void save(Forum aForum) { 
        EventStreamId eventId = 
                new EventStreamId( 
                        aForum.tenant().id(), 
                        aForum.forumId().id(), 
                        aForum.mutatedVersion()); 
 
        this.eventStore().appendWith(eventId, aForum.mutatingEvents()); 
    } 
} 

即使是只使用CQRS這一模式，也建議循序漸進，從簡單開始，最基本的，把QueryService 和 ApplicationService 分開，且在設(shè)計領(lǐng)域模型時不要受 QueryService 設(shè)計的影響。