如果不考慮資料庫的具體實現,只考慮程式碼中執行的儲存操作,大致可以分為以下幾種情況

1 有Repository 由repository.save(entity)來完成持久化操作

2 無Repository,由entity.save()來完成儲存

3 無repository,無entity.save(),在呼叫業務方法後自動儲存到資料庫

按照DDD書上的介紹推薦的是第一種,理由是把持久化的責任歸到entity會到導致混亂,有損entity專注於業務邏輯,也導致開發者的關注力收到影響(那就是為了保護你所以故意這樣做)

但是採用第一種也會導致一個問題,那就是繼承:

        如果有一個父類訂單Contract和兩個子類CommonContract和SpecialContract都有作廢操作並且含義一致.對於Application層有兩種方案,A方案是:

public ContractService{
    private ContractRepository repository;
    public Contract cancel(String id){
        Contract contract=repository.retrieve(id);
        contract.cancel();
        repository.save(contract);
        return contract;
    }
}

這樣就給ContractRepository出了一個難題,那就是我save到哪兒呢

B方案是提供兩個service

public CommonContractService{
    private CommonContractRepository repository;
    public CommonContract cancel(Stringid){
        CommonContract contract=repository.retrieve(id);
        contract.cancel();
        repository.save(contract);
        return contract;
    }
}

public SpecialContractService{
    private SpecialContractRepository repository;
    public SpecialContract cancel(Stringid){
        SpecialContract contract=repository.retrieve(id);
        contract.cancel();
        repository.save(contract);
        return contract;
    }
}
 

這樣做實現方雖然簡單了但毫無疑問增加了呼叫方的難度.一種緩解呼叫方難度的方案是採用Restful風格的介面,這個我後面會在restful風格api設計中介紹

B方案的另一個缺點是感覺沒有複用(這個問題也可以歸結於service這種東西本身就不夠OO)

也許有人會問第一種方案裡repository.retrieve()如何實現呢,這裡可以委託子類的repository(但子類太多而導致頻繁呼叫也是問題);但是在save的時候總不能把每個子類的repository都呼叫一遍吧.就算可以也會遇到方法不相容問題.原因如下

interface ContractRepository{
    void save(Contract contract);
}
interface CommonContractRepository{
    void save(CommonContract contract);
}
interface SpecialContractRepository{
    void save(SpecialContract contract);
}

從方法入參可以看出如果在ContractRepository裡呼叫CommonContractRepository裡save方法是要強制型別轉換的.

下面再說第二個方案:

public ContractService{
    private ContractRepository repository;
    public Contract cancel(String id){
        Contract contract=repository.retrieve(id);
        contract.cancel();
        contract.save();
        return contract;
    }
}

abstract class Contract{
     abstract void save();
     private boolean isCanceled;
    //這裡是個示例,實際操作與操作前的判斷及操作後的訊息通知可能更加複雜
     public void cancel(){isCenceled=true;}
}

這樣調至的一個明顯好處是體現了OO中的繼承,繼承在呼叫父類擁有的方法時很好用,不用care是哪個子類,但是作為入參並且要求方法對於不同子類採用不同操作時就比較麻煩了.

方案三可以避免方案一可能遇到的另一個問題,場景如下

        client發起了一個退費申請,然後本地服務受到請求後呼叫一個遠端第三方服務,在受到請求後返給client.這時會遇到一個問題,那就是由於網路原因或者程式碼bug導致遠端服務成功後本地服務沒有收到或者沒有寫庫成功,那麼當第三方提供對賬單時將無法在本地找到相應訂單記錄.所有一個解決方案就是在呼叫第三方前先寫一次本地資料庫,在得到呼叫結果後在寫一次本地資料庫.如果出了問題就等到對賬單到了找到本地的訂單記錄並把狀態改對就可以了.

        這個場景的解決也有兩種方案,一種是DDD推薦的使用Service來處理

class RefundService{
    private RemoteService remoteService;
    public Response refund(String accountId,Request request){
        Account account=repository.retrieve(accountId);
        account.refund(request);
        repository.save(transfer);//第一次
        Response repose=remoteService.refund(request);
        account.update(response);
        repository.save(account);//第二次
        return response; 
    }
}

這個在我看來讓Entity和Service責任混為一體,這樣導致只要有遠端呼叫就需要service的介入,這對今後一個服務拆分為多個服務是不利的.而採用第三種方案可以這樣處理

class RefundService{
    private RemoteService remoteService;
    public Response refund(String accountId,Request request){
        Account account=repository.retrieve(accountId);
        account.refund(request);
        repository.save(transfer);
        return response; 
    }
}
class Account{
    private RemoteService remoteService;
    void refund(Request request){
        //進行規制判斷
        if(getRemainAmount()<request.getAmount()){
            throw new InsufficientAmountException();
        }
        //儲存請求資料
        this.request=request;
        save();
        //更新執行結果
        Response response=remoteService.refund(request);
        this.response=response;
        save();
    }
    void save(){
        repository.save(this);
    }
}

這樣的好處是Entity處理了所有的業務操作,外邊的Application層只是負責把遠端呼叫(可能是json或xml格式,可能有加解密等等)轉換為一次對entity的本地方法呼叫.然後entity搞定其他的,甚至和其他微服務之間的互動也可以轉化為了一次對另一個Entity的呼叫.每次entity的寫方法結束後就會完成持久化和傳送訊息(而按照DDD書上介紹這是Application的責任)

上面講到的第三個方案有一個缺點,就是有時候我們接收到一次前端呼叫的時候也許不需要持久化.

比如一些帶確認動作的操作.就是使用者輸入了一些(例如使用了一個滿減紅包和一個折扣紅包),那麼頁面的顯示會隨之變動(例如訂單金額),有時是前端的資訊不足(例如該使用者是會員可以打折),如果這個計算操作後端是肯定要進行了,總不能拿著前端金額作為訂單金額,另外是紅包有可能被併發使用.總而言之就是後端不能信任前端的結果需要自己根據原始資料重新計算.這樣就導致了兩個問題,一個就是前後端計算結果可能不一致,就算一致也加重了前端的開發量.所以一個方案就是使用者在輸入時前端實時把資料拋給後端,由後端計算後返給前端呈現,這樣前端就只負責呈現而不用考慮業務邏輯.

這個時候後端需要提供兩個介面,一個是根據前端原始資料計算並返回,另一個是計算並儲存.可以看出來第二個方法是第一個方法+持久化.如果如果持久化本身就在entity的方法裡執行了豈不是entity還要專門提供一個計算但不持久化的方法.而我認為這是不必要的,這個可以通過service來控制

class ContractService{
    public Contract doRefund(String contractId,Request request){
        Lock lock=lockFactory.create(contractId);
        if(lock.tryLock()){//為防止併發而加鎖
            try{
                Contract contract=repository.retrieve(contractId);
                contract.refund(request);
                contract.save();
                return contract;
            }finally{
                lock.unLock();
            }
        }else{
            return null;
        }
    }
    public Contract calculate(String contractId,Request request){
        Contract contract=repository.retrieve(contractId);
        contract.refund(request);
        return contract;
    }
}

可以看出來entity專注於處理業務邏輯,而一些技術上的問題,例如持久化和加鎖交給了Service來處理.

也許你也注意到了,這樣會導致refund()內部無法save()的問題.