程式碼結構-可維護性程式碼

另外一篇比較好的文章如何編寫高質量和可維護的程式碼 http://www.codeceo.com/how-to-coding-best.html

好的程式碼結構.

api層

    -domain

    -view (亮點 組合層,不屬於純碎的領域,比如修給訂單費用介面,需要直接呼叫支付模組,然後透傳給訂單模組).  透傳的屬性用jsonString替代,泛化

biz層: 1.模組之間允許互相依賴.( 相當於互相的rpc呼叫 ) 2. 寫不能誇模組,需要模組封裝

integration: rpc呼叫的封裝層. 1.人力溝通隔離 2. 技術上變化遮蔽.

service層: 不能互相依賴.

    不要直接用列舉，而是用自建列舉介面，方便後續用類替換值，重構。

dao層.

     不要用繼承，用組合。例如orm繼承通用的dao，對於具體某個物件的create就很難梳理，散失了java的編譯優勢。

     有人的話用引擎模式，沒人的話用組合模式。

      有可能兩個模組之間的計算封裝又會產生新的類(模組): 舉例, 訂單和支付模組之前需要對 訂單的給的費用進行計算轉換. 給出支付費用.

同時.

分潤的費用也最好放到該模組內去. 隔離領域和變化. 實現高內聚,低耦合. 

模組劃分總的文章. http://blog.csdn.net/fei33423/article/details/51278704

只做儲存平臺+介面 還是 做包含業務的介面.

舉例:  操作日誌,有個type欄位.

只是儲存平臺. 不定義type的取值. type和key的唯一性有外部決定. 

做包含業務的模組. 不能讓呼叫方傳入type. 需要通過介面封裝掉.

微服務化會遇到這種基礎服務的問題: 導致唯一性不好統一控制. 一種是type ,另外一種是 redis key.

通過約定來控制. 字串字首.

另外一個問題是 組合服務view邏輯大量存在.