最近一個dish項目的建設思考

1. 系統通用能力的沉澱：a.核心模型的數據沉澱 b.通用服務能力的沉澱

   ps1：之前重心主要放在了業務的抽象和經過設計模式來增長可複用的擴展性。侷限在於，抽象的範圍會被單個業務或者當前的業務所束縛，在更大的範圍內，也許所作的抽象就沒法很好的起到它的做用。而通用能力的沉澱，在於每一個業務項目都會幫助積累一些通用的能力，這些能力能夠直接應用到其它的業務項目中，尤爲是在一些業務發展前景不是很清晰，業務多樣性比較高的場景。 更進一步，隨着系統的通用能力的積累和規劃，這些能力還會反過來影響和規範業務需求。 最後，全部的能力都有上下文限制，須要明確系統邊界。

   ps2：通用能力的沉澱，必然致使數據模型的職能更單一，致使上層的一個業務含義的表達須要聚合不少數據模型，從而大大增長數據操做的複雜度。反過來，數據模型的單一職能，致使了對通用服務能力的依賴，不然一每天寫mapper就寫死了（這裏的通用能力暗指的實際上是對聚合操做的通用能力）。

2. 多租戶：數據隔離，業務規則可配置化

3. 核心模型的重要性：模型的含義定位，模型的字段，模型之間的關係(聚合)。核心模型和通用能力的基石，對通用能力的影響和很是很是巨大的。根據模型聚合的邊界劃分，還能夠分出不一樣的應用服務，人員組織架構等等。

4. 系統包結構/模塊劃分: a. 三層架構(api,業務層,基礎建設層(dao,wrapper,util...)) b.四層(api,業務層,領域層,基礎建設層(dao,wrapper,util...)) c.根據系統職能的定位，在四層的基礎上，對業務層進一步進行拆分(1.首先是業務層總體的劃分：a.按照不一樣的業務 b.對業務流程的抽象 等進行劃分等等。 2.而後是每一個業務模塊下，再能夠建設該業務層下的通用層，業務流程抽象劃分等等)

   難點：1.業務層的抽象和劃分 2. 業務層內部的通用能力和領域層內的通用能力的界限(業務層的劃分對這個影響很大)

5. 系統交互：bc端分離(模型異構，bc端的業務區別大)，。。。

6. 以上的這些系統建設的知識是如何積累下來的呢？ 理論+實踐？看什麼書呢?(領域驅動？企業系統架構？)

7. 爲何在這個系統裏，對設計模式的東西感知的不多？是由於業務層劃分完以後，每一個業務功能都變得過小？是由於業務自己的特色？

8. 胡思亂想：設計模式的目的是幫助咱們實現 高可複用的高可維護性。 通用能力的建設，實現了很高的複用性，並且這種核心的通用層一旦創建後不多會須要再去修改。功能的擴展也許由於 數據模型和它自己的單一職能 而變的沒有那麼高的要求。 再加上業務層進一步的通用化建設和劃分得更小，致使了在這種狀況下設計模式變得不是那麼必要。 因此，設計模式在更加多變，複雜，細枝末節更多的業務層發揮的餘地更大。