從DDD開始提及

前言

從13年接觸DDD以後開始作應用架構已經整整四個年頭.
四年裏關於DDD的感觸良多,慢慢有了一些心得.
關於DDD的介紹已經有不少的文章和書籍,這裏我推薦三本最重要的書籍.

《領域驅動設計-軟件核心複雜性應對之道》（DDD）

《實現領域驅動設計》(IDDD)

《領域驅動設計模式,原理與實踐》(PPPDDD)

具體的DDD介紹這三本書已經很清楚了,可是學完這些以後我認爲DDD纔剛剛開始.
DDD給我更多的是一種設計啓發,不管是裏面的戰術設計,仍是戰略設計均可以展開到不少點.
書籍裏面不少時候只是一些設計原則,和一些簡單的demo,可是基於這些原則做爲出發點,能夠展開不少的設計.

架構有時候就是一個生長的,當我基於DDD爲起點,不斷演進架構.這時候架構彷彿也有了生命力,不斷地成長,到最後多是最開始徹底想一想不到的樣子,我想這大概就是架構的魅力.可是不管如何,DDD都是一個起點.

下面是我總結的基於DDD發散的一些知識體系

下面會有簡單的描述

---

倉儲

DDD中倉儲將持久化這個技術複雜性保持在領域模型以外.

具體來講有如下在具體實踐中有如下幾點：
1.隔離領域模型和數據模型：衍生出來就是隔離內存裏面的模型和持久化模型.這個點會在EAV的設計中體現的淋漓盡致.
2.技術複雜度的封裝：倉儲負責如何組織模型存儲.

靜態分庫:按照領域上下文(或者模塊)分庫,所謂縱向分庫,在程序啓動的時候就決定了某個實體該放到那個數據庫,因此稱之爲靜態.

動態分庫:當某個庫的數據量很大時候,這時候要對錶數據作切割,所謂橫向分庫.在程序運行時候,針對某個實體的某條數據才能決定放到那個庫,因此稱之爲動態.

3.規則橫切. 將一些面向切面編程的邏輯放到倉儲中.具體來講倉儲主要控制的就是CRUD

軟刪除:那麼只要在刪除和查詢的時候稍做處理便可實現軟刪除.

數據權限:只要在操做的時候判斷,查詢時候拼接條件便可實現數據的篩選.

---

應用程序服務

應用程序在我設計的時候我傾向於把契約和實現放到不一樣的項目中,基於這個偏好.慢慢演化出了以下思路

1. Abp中有個方式直接把應用程序服務暴露出能夠http訪問的api
2. 客戶端用動態代理的方式+ioc便可實現訪問契約,可是實際經過http請求調用
3. 實現幾個host方式,例如 IIS,Owin的Windows Service
4. 基於Host動態加載程序集

從1-4是一個遞進的過程,並不是一簇而就或者一次性想到,而是不斷重構優化產生的結果.

基於以上四步就已經接近一個應用程序容器.

PS: 這裏其實仍是剛剛起步 ,後續還有不少工做要作 ,目前還在實踐演化中.

PS：應用程序容器是從單體架構到微服務的一個重要的重構手段.

---

領域上下文

在DDD中涉及到領域上下文這部分,是在宏觀戰略層面的部分,偏重於業務架構層面.
在微觀中,涉及到的時候對某個類,或者某幾個類的抽象和設計.
在宏觀中,有時候須要把部分通用的功能進行抽離,即DDD中的支撐域.
另外上下文之間的通訊也是這裏要解決的問題.

1. 微服務:這部分網上不少資料不細說
2. 微應用:若是一個應用既有界面又有服務,我稱之爲微應用.
3. 上下文通訊:這部分涉及內部消息總線,外部消息隊列,另外結合以前應用服務容器中的動態代理部分的通訊方式.
4. 戰略設計： 其實就是部分支撐域的設計.雖然DDD中說更加看重核心域,可是在實際工做中發現,其實讓團隊成員集中精力
   對業務進行設計,抽離一部分公有業務會減輕程序員很大一部分負擔.

---

戰略設計

ACS

這部分重點有就是ACS(權限控制系統).其中按照不一樣層級分爲

1. 應用級別權限:控制應用和應用之間的訪問權限
2. 用戶級別權限:控制用戶帳戶對系統的訪問權限
3. 功能級別權限:控制用戶對某個功能的訪問權限
4. 數據級別權限:控制用戶對某條數據的訪問權限

基於功能級別的權限又演化出來一個邏輯應用的概念,實際應用是隔閡的,邏輯應用將多個系統功能合併成一個新的應用.

統計系統

基於每一個系統都會產生統計的須要,這裏引用CQRS的思想,將部分複雜的統計做爲查詢統一設計.

這個裏面最核心的部分就是動態查詢的設計.具體點就是將SQL和數據結構關聯.做爲SQL設計器的基礎.

組件服務

1. 計劃任務:有部分定時任務會用windows service的方式host.並用調用應用的接口來實現定時觸發.
2. 通知中心:將站內,短信,郵箱,微信,移動端,推送作抽象.
3. 附件:將附件的存儲和獲取與具體技術作隔離,並提供斷點續傳的功能.

---

聚合

其實這一部分發散開就是對業務邏輯的理解和設計.今年年初公司開始導入敏捷,感受又打開一片新的天地.
DDD說領域驅動設計,不少時候只是提了一個原則,可是具體該如何來.慢慢接觸到以下切入點：

1. BDD(行爲驅動設計)
2. 實例化需求
3. 用戶故事

在宏觀的業務需求梳理和分析的時候接觸到《用戶故事地圖》.

基於敏捷接觸到持續集成,慢慢接觸到DevOps.

基於DevOps還設計了一個自動化測試工具.

敏捷和devops,是今年一年重點在學習的地方,也在不斷的實踐.

固然目前仍是有不少問題急需解決.

---

總結

距離上一次發文已經好久了,有些知識常常不用就會忘記.

從這篇開始,會陸續有以上心得的分享,權當自我總結複習,歡迎你們討論拍磚.

由於不少是源於公司的經驗和業務,可能不會有所有的源碼,可是重點部分會有的.

我一直以爲現並不重要,重要的是設計.

可是如今不少人都是更加註重某行代碼怎麼寫.

如今互聯網這麼發達,這些具體技術點通常都很容易找到解決方案.

可是創新的設計思路倒是找不到的,這些我以爲纔是一個程序員的靈魂.