DDD - 概述 - (一)

本片將介紹如下內容:數據庫

  1).DDD是什麼?架構

  2).怎麼使用DDD?dom

  3).使用DDD應該規避或者注意什麼?異步

 

一.DDD是什麼?

簡言之:領域驅動設計(domain driven design),顧名思義,着重點在領域,這裏的領域指的就是具體的業務領域,一個業務能夠是一個領域或者多個子領域,每一個領域中包含多個子域.具體的實現更偏重於具體的業務知識,而不是技術的細節,說白了技術無關性了.spa

2. 咱們如何開始?

開始使用須要領域專的參與,須要領域專家對相應領域的業務分析,分析過程要注意 限界上下文:插件

1.核心域設計

  整個業務的核心領域並劃分限界上下文日誌

2.支撐域對象

  支撐其餘域的域,,,,好像有點蛋疼的說法,舉個栗子:假設當前系統爲電商系統,其中涉及到訂單這個核心模塊,這個訂單就能夠獨立成一個核心域,可是問題來了,訂單會涉及到用戶信息,以及用戶帳戶是否正常是否被凍結等權限的判斷,那麼這個用戶的信息的內容能夠獨立成一個子域,可是還一個問題,不僅是訂單會用到用戶信息,留言\評論\等等都會用到吧,那麼到這裏就很明顯了,這個就是所謂的支撐域了接口

3.通用域

  顧名思義,通用的模塊或者功能或者插件或第三方成熟的功能等等,好比,ids4.日誌,中介插件,熔斷重試等等

3.使用DDD應該規避或者注意什麼 ?

DDD實現,另外一方面,在咱們咱們須要注意點。這些都是:

1)使用一個以數據爲中心的視圖建模時的問題域

一般,數據模型的第一件事是一個架構師/開發人員將開始設計。他們老是認爲數據是最重要的,由於數據是咱們須要報告。若是你開始與DDD,必須改變這種心態。數據自己是沒有意義的。只有邏輯給數據意義,相同的數據能夠在不一樣的上下文中有不一樣的含義。所以,咱們必須從上下文和邏輯,而不是數據。

2)專一於實現細節等實體、值對象、服務、工廠、和存儲庫的核心概念

實體、值對象存儲庫等等沒有意義,直到咱們定義了通用語言,有界的狀況下,合同/製做軟件的接口。若是咱們開始早期與實體等實現細節,這是個好機會,結果將是一個域周圍不少服務和業務邏輯分散無處不在。

3)使用泛型和Developer-Specific術語和概念在實現應用程序

咱們不該該使用概念,好比保存、更新、刪除、處理、管理、等。這些概念太技術——抽象的概念,沒有具體的意義。相反,咱們必須專一於業務概念。上述的概念(即保存、更新等)不相關的業務概念。要理解這一點,我老是鼓勵本身想象沒有電腦客戶端運行他的差事/業務(手動作特定的任務)。因此,老是想從業務/領域專家的角度來看,和給一個明確的上下文。避免通用術語,可致使不一樣的含義在不一樣,非特異性背景。

4)高估了數據庫事務,而不是專一於業務流程或事務

在DDD,商業交易比DB更重要的事務。數據庫事務是ACID(原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、持久性(Durability)),和短期運行的,而商業交易。事實上,在現實生活中,咱們不知道數據庫事務,瞭解業務事務。例如,想象一下當你坐在餐廳,點一些食物或飲料。在訂單事務,實現與否,將會有一個過程與一些異步任務不少可能的變化不一致的狀態;但最後,全部狀態都將一致(最終一致)。所以,與DDD,永遠不要考慮數據庫事務。相反,老是思考現實世界的過程,如行爲和可能的結果,若是發生失敗如何彌補該行爲或結果。

相關文章
相關標籤/搜索