為什麼使用DDD？

ddd為什麼火了？

第一次聽到ddd這個詞是在幾年前。乍一聽感覺像tdd（測試驅動開發），但其實它們完全是兩回事。當時看了一篇介紹ddd的部落格，一大篇專業術語，搞得雲裡霧裡，便沒有深究下去了。

ddd到底是什麼鬼？

ddd是當今業界唯一乙個包含了從需求分析到落地的工具。ddd將重心放在業務上，從業務出發來設計**，業務是ddd的中心。

ddd分為戰略部分和戰術部分，兩者相輔相成。戰略部分用於理解、梳理業務，找到核心業務，更好地劃分系統（這也是ddd為什麼可以用於指導微服務設計的原因）；戰術部分用於落地到**上，用**來清晰地表示業務，**如何分層、如何設計都有一套成熟的指導方案。

ddd可以比較好地解決複雜業務的軟體開發，但ddd不是「銀彈」，ddd也並不是一些死板的術語和規範。事實上，當今業界仍然在ddd的實踐道路上探索前行。

銀彈：某種便捷的開發技術，從而使某個專案的實施提高效率。

ddd同樣不是唯一的選擇，只是可以作為眾多任務具箱中的乙個，在衡量成本和收益之後，可以取出來結合其它工具一起使用，為自己的業務服務，為自己設計更好的軟體服務。

所以「領域」到底是什麼？

所以「領域驅動設計」這句話後兩個詞很好理解，但「領域」到底指的是什麼？

ddd通過分析業務，最終構建成乙個個「領域」，設計出乙個個富含業務行為的、飽滿的「領域模型」。

在ddd裡，「領域」指的就是一塊業務範圍。比如在乙個電商系統中，可能會有「商品領域」、「訂單領域」、「物流領域」、「倉儲領域」等等。ddd通過戰略部分指導我們根據業務劃分出業務領域，並區別出哪些是核心領域，哪些是支撐領域和通用領域。這個我們會在本系列後面的文章中詳細解釋。

「領域模型」指的是業務的載體物件，比如「商品」、「訂單」等等。這些物件具有一些有業務含義的方法，比如「商品.加入購物車」方法。我們把主要的業務邏輯內聚在領域物件裡，這樣乙個操作要做的事情就變得非常清晰，並且易於維護。

簡單來說，「領域」和「領域模型」能夠更直觀地表現業務，把業務真正落地到系統架構和**設計上。

為什麼需要ddd？

「即使我們的軟體中沒有bug，也不能表示我們設計的軟體模型本身就是好的」。使用ddd，能夠讓我們的軟體設計更加合理，但不止於此。

對於乙個業務複雜的系統而言，使用ddd有如下好處：

什麼時候需要使用ddd？

使用ddd是有一些成本的，你的團隊成員需要去了解ddd的一些基礎知識，最好還需要有人做過ddd方面的實踐，有一定的經驗。

做任何事情都需要衡量成本和收益，技術方案的選型也不例外。ddd有一定的成本，但也能帶給我們顯而易見的收益。

一般來說，ddd適用於「業務複雜」的且「需要維護和擴充套件」的系統。

首先，我們來看看什麼叫業務複雜。試想一下，如果你的系統只需要對幾個簡單的表進行crud，那你不需要使用ddd，甚至都不需要開發乙個應用程式，直接使用乙個資料庫客戶端可能就能解決問題。

從經驗上來看，如果你的系統有30個以內的業務操作或使用者故事，那也是沒有太大必要去使用ddd的。而如果超過三四十個，軟體就會有一定的複雜性，這個時候就可以考慮使用ddd了。

另一方面來說，即使現在這個軟體並不複雜，但後續會進行開發和擴充套件，在可以預見的將來，它會變得複雜，那也可以考慮使用ddd。而一些初創公司，它們或許只需要乙個簡單的產品來快速測試市場反饋，後續並不會繼續開發和維護，而是考慮重新購買或者從頭開發的話，那也沒有必要浪費成本去使用ddd。

所以再次總結我們什麼時候需要使用ddd呢？業務複雜且需要長期維護的時候。

總結其實縱觀全文，可以發現ddd的核心就是乙個詞：業務。ddd的一切工具、實現都是以業務為中心，從業務展開的。所以如果要想實施好ddd，一定要認清業務的價值，關注業務，理解業務。