(3) 基於領域分析設計的架構規範-讀寫隔離

本系列目錄：

1. 改變與優點
2. 領域分析基礎
3. 讀寫隔離
4. 充血模型之實體
5. 充血模型之Service
6. 關於重構與落地

思想概述

讀取操做必須是無害的，暫時不考慮大併發把服務器壓垮這種極端場景，就通常而言，咱們能夠說，一個合格的查詢接口所達到的效果應該是： 不管你執行多少次查詢，系統的數據都是不會發生變化的

因此，對於一個陌生的系統，若是對方給了你【增刪改查】四個接口，那麼再沒有深刻了解業務的狀況下，你首先進行測試的接口，必定是查詢接口

爲了達到一個合格的查詢接口，對於系統的開發者的來講，必須保證全部的查詢業務接口裏，不能有任何對業務實體的修改操做，換句話說，全部的查詢操做，只是對系統瞬時的一個快照，不對數據產生修改，天然對整個系統的業務運轉也不產生任何變更。

實現策略

咱們常說的讀寫分離，那是在應對性能問題時的一種解決方案。而咱們這裏特地換成了讀寫隔離，就是爲了區分開二者。而這個隔離，是從更高層面來設計整個架構規範，是在項目設計剛開始的時候就考慮進去的。並且，實現難度小。

即便是基於現有的代碼作重構，也只要挪代碼塊就好了，也沒有什麼業務風險，這個咱們以後會再提到。

那麼，很天然的，經過@Transactional(readOnly = true)的控制，能夠很是好的達到這個目的，這樣，即便有開發人員不當心在其中作了修改操做，也會執行報錯，給予很好的安全提示，這時，咱們就須要從新審視這個需求，是否須要將修改操做分離出來。

import org.springframework.stereotype.Service;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.transaction.annotation.Transactional;

/**
 * 以訂單爲主體的查詢業務處理類
 */
@Service
@Transactional(readOnly = true)
public class OrderFinder {

    @Autowired
    OrderRepository orderRepository;
    @Autowired
    UserRepository userRepository;
     
     /** 批量查詢訂單 */
     List queryOrderByIds(List<Long> orderIds)
     
     /** 運營控制檯訂單分頁查詢 */
     List pagingOrdersOnConsole(int pageSize,int pageNumber)
     
     /** APP端用戶訂單分頁查詢 */
     List pagingOrdersOnApp(Long userId,int pageSize,int pageNumber)
     
     // more methods and fields ..
}

·

有一些問題直得探討：

Finder就等同於將Repository裏的查詢方法挪過來嗎？

並非，首先，Finder是一個查詢業務的處理類。一個查詢業務，意味着從調用端發起請求到結果返回，本次過程是進行一次完整的查詢操做，更直觀的來講，像是下面這樣

//..在一個入口層中，好比SpringMVC中的@Controller
    
    @Autowired
    private OrderFinder orderFinder;

    @GetMapping("/paging/")
    public CustomPagingResponse pagingOrders(int pageSize,int pageNumber){
          return orderFinder.paging(pageSize,pageNumber);
    }

而並不是另一種爲了刪改某一個實體而經過主鍵或其餘特定查詢SQL來作出的查詢操做，這種操做，將會在一個命令業務中直接經過Repository去作，好比

//..假定是在訂單刪除業務OrderDeleteService中的一部分
    
    public void deleteOrder(Long orderId){
    
        //根據條件定位到須要進行操做的Entity，這個過程，是命令操做的一部分，因此，它不是一個完整的查詢業務，這個時候，不會用到Finder
        Order order = orderRepository.getById(orderId);
        
        //...接下來對order進行操做，省略
    }

並且，每每在一個較爲複雜的查詢業務中，不只僅須要從數據庫中獲取數據，每每可能還須要經過各種協議的遠程接口獲取數據，進行整合，這就更加須要Finder來進行概括處理了。

·

每一個實體（Entity）類都須要有一個Finder嗎？

並不必定，由於並非每一個實體都會有這種業務需求。好比咱們很容易想到，對於訂單，會有不少終端須要經過各種條件查詢訂單列表，也會有某一條訂單的詳細信息。但相比之下，訂單變動記錄，可能惟一會被查詢到的地方只會是在訂單詳情中的一個小列表，那麼，實現的寫法更傾向於以下這種：

public void OrderFinder{
    @Autowired
    private OrderTrackRepository orderTrackRepository;
    
	//它依舊出如今 OrderFinder 中
    public OrderDetailView queryOrderDetail(Long orderId){
    
        //首先查詢order基礎數據
        
        //而後補充查詢訂單變動數據
        List<OrderTrack> orderTracks = orderTrackRepository.getByOrderId(orderId)
        
        //而後整合，返回整個View
    }
}

因此，因爲它只會存在於訂單View中的一部分，天然不須要單獨一個OrderDetailFinder。固然若是將來OrderDetail的代碼量陡增，那是能夠考慮重構的。

效果

其實你們回看本身現有的項目，裏面有不少諸如【報表】，【採購單】，【詳細信息】等等，其實，都是系統某一個側面的快照而已。

將這些東西都一一隔離出來，這個時候，再去審視整個系統，你會有一種雲開霧散，柳暗花明又一村的感受。

由於剩下的命令操做，就是整個系統的脈動了。

詳細參看以後的章節~

下一篇 充血模型之實體