談談代碼:DDD從入門到完全入門

本文首發于泊浮目的簡書:http://www.lxweimin.com/u/204b8aaab8ba

版本 日期 備注
1.0 2021.8.22 文章首發
1.1 2021.8.26 增加對于核心思想的描述

之前的DDD文章——談談代碼:降低復雜度,從放棄三層架構到DDD入門,通篇下來像 是簡單的講了一些概念,然后快速的實戰一下——很多同學反饋感覺就是入門了,但沒有完全入門,因此我們再加一篇。

1.什么是DDD

先看下萬能的維基百科:Domain-driven design (DDD) is the concept that the structure and language of software code (class names, class methods, class variables) should match the business domain. For example, if a software processes loan applications, it might have classes such as LoanApplication and Customer, and methods such as AcceptOffer and Withdraw.

這邊將其稱為了一個概念。在我看來DDD是設計模式的超集,一種指導思想——用來指導如何解耦業務系統,劃分業務模塊,定義業務領域模型及其交互。

2. DDD誕生的背景

領域驅動設計這個概念并不新穎,早在 2004 年就被提出了,到現在已經有十幾年的歷史了。不過,它被大眾熟知,還是基于另一個概念的興起,那就是微服務。因此在實現的時候樣子不一定是一模一樣的,更多時候還是根據業務場景來因材施教。

3. DDD的核心思想

核心思想是讓技術復雜度與業務復雜度隔離,并通過統一語言組織業務邏輯,降低認知成本。

具體主要體現在:

  • 基礎設施層:它負責隔離技術復雜度,通過抽象封裝來對內提供服務,而不是讓內部服務直接使用它。這意味著當外部基礎設施變化時,業務并不會被迫進行變更。比如項目中的數據總線是Kafka,之后替換成了Pulsar,業務對其應該是無感知的。
  • 厚領域層:同一領域的知識聚合在一個領域中,領域知識不再被割裂。這是單一職責原則的一種體現。
  • 實體:用充血模型代替貧血模型,完全符合面向對象的思想。將業務中的對象完全投射到實體中,從面向資源轉換成面向過程和面向對象。

4. DDD能解決什么樣的問題

一般軟件會經歷幾個不同的周期:

  1. 大煙囪:每個應用各自為政,類似的需求重復開發,浪費人力
  2. 服務化:根據不同的業務屬性拆分服務。關注服務拆分、服務治理、模型抽象
  3. 平臺化:將相關的微服務同一成一個平臺暴露出來。關注領域收斂、領域自治、能力沉淀
  4. 中臺化:將通用能力下沉至中臺,快速響應前端服務。需要關注數據打通、能力串聯、業務響應力

DDD主要在技術密集型應用里有較大的作用,尤其是當該應用進入服務化、平臺化時,可以在:“服務拆分”、“服務治理”、“領域收斂”、“領域自治”發揮。在中臺化中的“數據打通”也有一定的作用。

而微觀來說,DDD可以有效減少代碼的冗余程度以及需求響應的速度。

5. DDD實踐中要注意的

5.1 使用IOC來保證層次之間的隔離

經常有小伙伴問我,分層之間該怎么做?因為分層的邊界沒做好,代碼會再度耦合再一起。對此我給出的答案是參考inversion of control。其常見實現有:

  • Object Dependency Inject
  • Service Provider Interface
  • Strategy
  • Abstract Factory

也可以參考我之前寫的文章:技巧:遵循Clean Architecture寫好白盒測試

5.2 模塊分離

模塊分離是一種較為“硬”的手段,它讓分層不再是一個約定,而是強制執行的規則。這樣當我們拆分微服務時候,也可以較快的完成拆分。

5.3 DDD并不是只有三層到四層

也有小伙伴問過我,轉DDD的是否只有三層過來的?其實并非如此。我這邊可以舉兩個例子:

5.3.1 流計算處理

我們以面向在線數據加密應用為例子:當一條數據流過我們的應用時,我們需要根據一些條件對其加密。

應用的基本流程為:Source(from kafka) -> Map(encryption) -> Sink(to kafka)

那么代碼中,kafka其實是基礎層的代碼。而encryption屬于領域層,map(框架)和encryption之間的膠水代碼則屬于基礎層。

5.3.2 GUI應用

相信大家都在學生時代學過GUI or HTML 編程。那么按照DDD的做法來,業務邏輯應該與具體的界面無關——比如界面上的一個按鈕(數據模型)會觸發一種事件,當后臺的事件接受者收到這個事件時,則會尋找相應的執行者,執行對應的邏輯。

在這里面:

  • 界面可以是Qt,可以是Flex,可以是Ios,可以是Android,也可以是Vue。其本質是用戶接口層。
  • 后臺的事件接受者是基礎層。
  • 具體的執行邏輯則放在領域層。
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 230,825評論 6 546
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,814評論 3 429
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 178,980評論 0 384
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 64,064評論 1 319
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,779評論 6 414
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 56,109評論 1 330
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 44,099評論 3 450
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 43,287評論 0 291
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,799評論 1 338
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,515評論 3 361
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,750評論 1 375
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,221評論 5 365
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,933評論 3 351
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,327評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,667評論 1 296
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,492評論 3 400
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,703評論 2 380

推薦閱讀更多精彩內容