DDD領域驅動設計落地實踐系列：初識DDD

引言

筆者在經歷的很多專案中都使用了DDD領域驅動設計進行架構設計，尤其是在業務梳理、中臺規劃以及微服務劃分等方面，DDD是重要的架構設計方法論，對平時的架構設計有非常好的指導作用，從本文開始筆者將通過一系列的文章闡述自己對于DDD的理解以及如何在專案實戰中落地實踐DDD，本文作為系列文章的開端，主要和大家聊聊DDD的一些基本概念以及常用方法，

DDD到底是何方神圣？

軟體設計方式

我們的軟體開發模式可以分為幾種類別，分別是DL驅動開發、資料驅動設計以及DDD驅動設計，實際上就是代表了我們不同的開發階段，有種從粗獷到精細的階段晉級的感覺，這就好比一個初入職場的萌新，到有一定經驗的老鳥，再到精英的打怪升級程序，下面我們分別來看下這幾種軟體開發模式，

DL驅動開發：即DeadLine驅動開發，給定一個截止日期，只要在這個DL之前完成所需要的功能就可以，至于設計的什么的不關注，基本缺乏程序管理，只追求短期的業務目標，因此對應的代碼可能就是一坨一坨的，難以擴展維護，給日后埋下巨大的技術坑，

資料驅動設計：這大概是我們最常用的軟體設計方式，需求過來后先進行資料庫表設計，再通過資料流向去串聯對應的業務流程，基本可以應付大多數的應用服務場景，

DDD領域驅動設計：我們接觸的系統越來越龐大了，涉及的子系統也越來越多了，傳統的軟體設計方式已經不能滿足我們應對復雜系統的設計，而DDD提供了我們應對大型復雜系統的領域建模以及分析的方法論，

第一種方式咱們就不說了，我們可以來看下資料驅動和DDD領域驅動設計，其實這兩種設計方式最大的不同就是設計思想的轉變，基于資料驅動的設計方式關注具體的業務資料承載，先通過確定對應業務的資料物體，而后完成資料庫表的設計，再通過具體的業務流程把這些資料連接到一起從而完成軟體設計，在一些簡單的小的系統中，使用這種設計方式完全夠用了，
但是隨著業務不斷的發展，微服務的落地實踐，特別是大廠中極其復雜而又龐大的業務，光靠資料驅動設計難以實作，而DDD關注領域模型，通過領域模型驅動整個系統的軟體設計，讓那個領域模型與資料模型解耦，明確業務邊界，從而能夠更好的指導我們完成復雜系統的架構設計，

DDD

上文中通過不同軟體設計方式的描述，引出了DDD領域驅動設計模式，那么我們就來看下DDD到底是什么，所謂DDD即Domain Driven Design，字面意思就是領域驅動設計，其實它并不是什么新鮮玩意，早在2004年著名建模專家Eric Evans在他的頗具影響力的書中《Domain-Driven Design –Tackling Complexity in the Heart of Software》（領域驅動設計：軟體核心復雜性應對之道）已經提出來相應的概念，但是實際上國內各個互聯網大廠能夠把DDD應用好的并不多，
DDD不是一種架構形式，它是一種架構設計的指導思想，是一種應對復雜域問題的方法論，他可以協助我們設計高質量的軟體模型，尤其是在復雜、大型軟體系統的場景下，DDD尤其可以發揮其獨特的作用，

我們除了理解DDD的知識，我們更希望在實際作業中運用這種軟體架構設計的思想，但是這并非一件容易辦成的事情，想要真正的落地實施DDD必須滿足以下兩個條件：

1、統一認識：DDD不是誰的獨角戲，需要整個團隊自上而下對于DDD有比較深刻的理解以及認同，雖然DDD是架構技術實踐，但是其正向價值最侄訓傳到業務端形成相應的業務價值，
2、貫徹實施：有了理論指導和深刻認識還不夠，我們還必須在實際作業中進行貫徹實施，也許這個程序會有陣痛，但是只要熬過去，對于整個團隊來說，必定是架構設計層面的一次躍升，

另外補充說明一下，DDD本身在理解上面就有一定的門檻，即便我們把各種概念都理解了，也不一定就能把DDD在我們的實際作業中完美落地，因為它不僅僅關乎軟體架構設計，更是整個團隊如何進行貫徹實施的問題，我想這也是DDD沒有大規模應用的原因，

為什么需要DDD？

通過上文，我們對DDD有了初步的了解，知道他是一種應對軟體復雜度的架構設計方法論，那我們先來看一個問題，那就是到底哪些因素導致了軟體設計的復雜性，因為只有搞清楚了軟體復雜度的因素，我們才能更加理解我們為什么需要使用DDD來應對越來越復雜的軟體系統設計，
我們在實際的專案開發中經常會遇到這樣一些問題，經常為了到底這部分業務是你的小組負責修改還是對方小組的修改而吵得臉紅脖子粗，

1、業務復雜度高

需求堆積如山，業務規模隨著時間的推移也在不斷增長，系統又很龐大，不同業務之間相互影響，就拿電商業務來說，就有商品服務、用戶服務、庫存服務、訂單服務、積分服務、優惠券服務、物流服務等等幾十個微服務類別，組成了非常復雜的業務系統，
業務系統多的情況下，業務邊界由于歷史原因也存在劃分不清晰的問題，系統之間各種依賴，一旦來了個牽扯很多子域系統的大專案的時候，經常會因為業務邊界問題，團隊之間扯的臉紅脖子粗，實在勞心勞力，

2、業務需求變化快

互聯網行業各個業務板塊競爭都非常激烈，誰能更快推出更加便捷、更加符合用戶預期的產品，誰才搶奪市場，占領市場先機，因此相應的商業流程自然變化快，業務今天是這樣的流程，明天就變了，這種不斷變化的場景以及需求對整個軟體系統帶來了非常大的設計挑戰，

3、跨團隊協作難*

一個大專案，很大情況下需要各個子域的團隊進行通力合作才能完成，來完成業務的全鏈路，如果沒有統一的業務語言，那么必定導致團隊之間的溝通效率低，甚至出現業務傳達層層遞減的情況，團隊之間的反復溝通也會增大設計人員、開發人員的溝通成本，
如上所述，我們在設計軟體架構的時候需要考慮到如何更好的實作需求、更好的應對不斷變化的需求以及更好的和他人協作來實作，因此傳統的資料驅動設計的方式無法滿足我們的實際需要了，要是有一種架構設計模式可以支撐我們應對上述的這些挑戰的話，那該是多么幸福的一件事情，
因此，綜上所述，我們需要一套架構設計的方法論來指導我們進行復雜業務系統的設計，那么DDD就是一個非常不錯的選擇，

DDD的價值

通過上問的描述，我們大概知道了為什么需要使用DDD來實作軟體架構設計，那么DDD會給我們帶來怎樣的價值呢？
統一業務語言：通過使用統一的領域語言，消除了團隊間的分歧，提升團隊間的溝通效率，
沉淀業務知識：通過領域模型沉淀領域知識，提升業務建模能力，清晰表達業務核心語意，
清晰業務邊界：統一各個子域的認識，通過領域模型界定需求實作邊界，表面無休止的團隊之間扯皮，拉通團隊認知，
提升變化應對：通過領域模型與資料模型的分離，將核心業務的不變與需求的變進行有效隔離，提升架構應變化的能力，

DDD重要概念

統一語言

秦始皇統一六國之后，首先做的就是在全國范圍內進行了文字、度量衡、錢幣的統一，其中統一文字，就是為了方便各個地域人們的溝通交流，為實作中國的大一統奠定了基礎，

那么在DDD中，就是要在領域專家、設計團隊、研發團隊中建立一套統一的業務術語體系，讓大家對于領域知識在描述層面上達成一致，從而解決各個團隊之間的溝通協作問題，這里的統一語言主要體現在兩個方面：
（1）統一的領域術語：所謂領域術語就是在該領域內的各個物件在命名上達成一致的共識，例如在庫存領域中的SKU，各個團隊都知道SKU代表的是庫存進出的計量單位，這樣在進行業務討論的時候，一提到SKU大家就都知道它所帶代表的含義了，不用再進行過多的解釋說明，
（2）統一的領域行為：領域行為就是領域的行為描述，例如在庫存域中涉及的貨物的上架動作就是屬于該領域的特有領域行為，因此我們可以看出來，領域行為是一種從領域模型角度來進行行為的描述而不是具體的實作角度，

領域模型

在搞清楚什么是領域模型之前，我們看下《領域驅動設計》中關于領域的定義，

領域即是一個組織所做的事情以及其中所包含的一切，商業機構通常會確定一個市場，然后再這個市場中銷售產品和服務，每個組織都有它自己的業務范圍和做事方式，這個業務范圍以及其中所進行的活動便是領域，

這個定義看上去有種不明覺厲的感覺，我們還是以大家最熟悉的電商場景來進行說明下，電商系統中以用戶購物為例子，用戶瀏覽商品之后，選擇了對應的商品進行下單，在生成訂單之后，積分服務隊用戶的購物積分進行增加，庫存服務將對應商品的庫存進行扣減，優惠券服務向用戶發放新的優惠券，物流服務將接管后續的成品物流資訊，在這個典型的用戶下單購物場景下，用戶服務負責提供用戶資訊以及用戶的統一管理，那么關于用戶的一切操作都是在用戶域完成的，包括用戶的名稱、密碼等資訊的維護以及注冊、登錄等動作的實施，那么我們可以認為這里的用戶服務就是用戶領域，它是這個電商系統中的一個子域，

對于領域模型來說，我們可能會任務它是一個大而全的能夠概括整個業務系統的全能型的模型，實際上不是的，定義這樣一個模型也是十分困難的事情，在實際落地實施程序中，我們更加愿意在各個子域中實作領域模型的建立，而這個領域模型就在這個限界背景關系中完成實作，

所以說領域模型就是針對某個特定業務領域的軟體模型，如電商業務領域中的訂單、積分、庫存、配送等都是電商業務領域的子域，領域模型通過物件模型描述真實的業務場景，精確表達業務語意，它是實際業務場景中的流通貨幣，

在整個業務團隊中，領域專家、設計人員、開發人員需要對領域模型有統一的認識，大家都認可，在不同的子域中就會有不同的領域模型，那么我們怎么來區分不同的領域模型呢，實際上就是通過限界背景關系來進行區分，

限界背景關系

這個概念怎么說呢，既好理解，又不好理解，限界背景關系是一個顯式的概念性邊界，我們的領域模型都是此邊界中，我們都知道領域模型是使用同一語言描述的軟體模型，每個領域模型都有對應的屬性和動作，這些屬性和動作需要在一個特定的背景關系環境中才有特定的意義，打個比方，筆記本在文具領域那么它就是一個紙質的記錄工具，同樣是筆記本這三個字但是在3C領域中，它指的又是我們常用的筆記本電腦，同樣的名稱但是在不同的邊界背景關系中代表的含義是完全不同的，因此實際上，限界背景關系為團隊創建了一個建模邊界，團隊成員在邊界內部實作解決方案，

通過上面的例子我們可以把限界背景關系理解為一種農場中的圈子，有的圈子是養豬的、有的圈子是用來種植蔬菜的，如果沒有限界背景關系那么豬就有可能把蔬菜吃過了，但是有了圍欄（限界背景關系）之后，我們可以在不同圈子中進行喂養或者灌溉，互不影響從而使得農場可以很好的運轉起來，農場的圈子和圍欄我們可以實實在在看的到，那么到了軟體系統中領域邊界就是一種抽象視圖，

如下所示，在電商這個業務領域中，包含了訂單、物發票以及庫存等子域以及對應的限界背景關系，

總結

本文主要圍繞什么是DDD進行了說明，并分析了軟體架構設計存在的復雜性，因此我們需要DDD這種復雜架構分析方法協助我們完成，通過上文我們大致了解了DDD是干什么用的以及一些重要的概念，那么下篇文章我們將介紹下DDD的實作步驟，以及幾種常見的實踐方法，

大家好，我是慕楓，感謝各位小伙伴點贊、收藏和評論，文章持續更新，我們下期再見！

真正的大師永遠懷著一顆學徒的心

微信搜索：慕楓技術筆記，優質文章持續更新，我們有學習打卡的群可以拉你進，一起努力沖擊大廠，另外有很多學習以及面試的材料提供給大家，

幾乎全新的鍵盤，自己就用了兩次，有朋友送了另外的鍵盤，本來打算在咸魚上賣掉的，后來想想不如在我的公眾號以及CSDN粉絲中抽一位直接送了，沒有套路，全國包郵送，快來領取秋天的第一個雷蛇鍵盤吧，