單塊系統分解小結

單塊系統把全部不相關的代碼放在一塊兒，修改一行代碼沒法保證對其餘部分形成影響。並且爲了發佈一個小的功能須要整個系統從新部署。

1.     識別系統中的高層限界上下文，好比業務邊界。

2.     建立包結構來表示這些上下文，把代碼移動到相應的位置

3.     分析包之間的依賴。代碼之間的依賴關係應該跟組織（好比按照業務區分包結構，組織應該是業務）中不一樣部分的實際交互方式一致。若是不一致分析爲何這樣並解決。

4.     增量改造單塊系統

5.     邊界肯定，代碼也分離完成，接下來須要抽取某個包中的所有代碼，建立單獨系統，抽取哪一個部分要考慮得到的收益是否最大。收益能夠考慮以下幾個因素：

改變速度：後期可能對某個方面進行大量修改，若是抽取出來做爲一個服務的，使其成爲一個自治的單元，對後期的開發速度將大大加快

團隊結構：交付團隊分佈在兩個不一樣地區，誰維護的分離給誰

安全：某個服務擁有敏感信息，須要作更加嚴密的保護，若是把這個服務分離出去能夠對這個單獨的服務作監控。傳輸數據的保護和靜態數據的保護

技術：特定的服務須要特定的技術，好比其餘語言，可以大大改善咱們的服務，那麼能夠分離出去做爲一個單獨的服務

6.     抽取出來的服務應該儘可能少地被其餘組件所依賴

7.     對dao層進行劃分，把數據庫映射相關的代碼和功能代碼放在同一個上下文中

8.     不一樣模塊提供API方式進行數據訪問，不能經過數據庫集成方式。而後去除數據庫外鍵關聯約束，經過代碼來實現這個約束。

9.     共享靜態資源的處理：

            a 每一個包複製一份該表的內容，將來每一個服務也會保存這樣一份副本，若是增長一個屬性，後期維護困難

            b 共享靜態數據放入代碼，好比屬性文件，枚舉類，也會出現a中的問題，不過操做簡單的多

            c 做爲單獨服務，若是值得咱們這麼作的話能夠考慮

10.  共享數據的處理：共享數據意味着一個表被多個模塊共享，讀寫數據。領域概念不是在代碼彙總進行建模，相反是在數據庫中隱式建模。共享數據表多是咱們缺失的領域概念，意味着共享數據表能夠具象話，做爲一個新的包，最終能夠獲得一個清晰的客戶服務

11.  共享表的處理：因爲兩種實體字段相似，最初處於方便把他們放在了同一個地方，即比較通用的行條目表。當把代碼所有放在一塊兒時，事實上很難意識到咱們把不一樣的關注點放在了一塊兒。解決方案就是按照兩種實體分紅兩個表。

12.  先分離數據庫結構後分離服務。好處在於能夠隨時選擇回退這些修改或是繼續作，而不影響服務的任何消費者。咱們隊數據庫分離感到滿意以後，就能夠考慮對整個應用程序的分離了。

13.  事務處理：分離服務後兩個寫操做可能不在一個事務裏，解決一致性方案有：

        a 最終一致性 ：第一個寫成功後，第二個寫操做能夠放入隊列、日誌文件中，或者其餘方式，以後嘗試對其進行處罰，確保在將來的某個時間達到一致

        b 拒絕整個操做：第二個操做失敗後發起一個補償事務來抵消以前的操做，好比一個DELETE操做把以前的操做記錄刪除，而後向用戶報告該操做失敗了

        c 分佈式事務：橫跨多個事務，而後使用一個叫作事務管理器的工具來統一編配其餘底層系統中運行的事務。這裏的事務會運行在不一樣系統的不一樣進程彙總，一般他們之間使用網絡進行通訊。經常使用的算法是兩階段提交

參考《微服務設計》