如何一步一步用DDD設計一個電商網站（一）—— 先理解核心概念

本系列全部文章

如何一步一步用DDD設計一個電商網站（一）—— 先理解核心概念

如何一步一步用DDD設計一個電商網站（二）—— 項目架構

如何一步一步用DDD設計一個電商網站（三）—— 初涉核心域

如何一步一步用DDD設計一個電商網站（四）—— 把商品賣給用戶

如何一步一步用DDD設計一個電商網站（五）—— 停下腳步，從新出發

如何一步一步用DDD設計一個電商網站（六）—— 給購物車加點料，集成售價上下文

如何一步一步用DDD設計一個電商網站（七）—— 實現售價上下文

如何一步一步用DDD設計一個電商網站（八）—— 會員價的集成

如何一步一步用DDD設計一個電商網站（九）—— 當心陷入值對象持久化的坑

如何一步一步用DDD設計一個電商網站（十）—— 一個完整的購物車

如何一步一步用DDD設計一個電商網站（十一）—— 最後的準備

如何一步一步用DDD設計一個電商網站（十二）—— 提交併生成訂單

如何一步一步用DDD設計一個電商網站（十三）—— 領域事件擴展

 

閱讀目錄

• 前言
• 名詞解釋
• 實施DDD的關鍵
• 如何構建一個領域的上下文映射圖
• 構建咱們的上下文映射圖
• 結語

 

1、前言

    DDD（領域驅動設計）的一些介紹網上資料不少，這裏就不繼續描述了。本身使用領域驅動設計摸滾打爬也有2年多的時間，出於對知識的總結和分享，也是對自我理解的一個公開檢驗，介於博客園這個平臺也算是對DDD的推廣盡了一份綿薄之力。一開始接觸這個東西是在2014年，真的以爲像是發現了一片新大陸通常，對我整個程序開發視野有了新的理解，可是像[Vaughn Vernon]《實現領域驅動設計》裏寫的那樣，景色雖好，但是本身很長一段時間內很混亂，理不清眼前的陌生世界，由於它與傳統的觀念徹底不一樣。我相信大部分同窗剛接觸DDD的時候也會有同樣的感受。

    此次開始寫這系列，也但願有愈來愈多的人可以加入到DDD的隊列中，在我以前，園子裏的netfocus、dax.net、田園裏的蟋蟀等園友都已經對推廣DDD作了不少事情，再此感謝下各位，這些分享在我學習DDD的道路上給予了不少幫助。

    本次系列中多處引用[Vaughn Vernon]《實現領域驅動設計》一書裏的語句，我認爲此書能夠做爲各位進入DDD的敲門磚，但願你們可以去拜讀一下此書。

 

2、名詞解釋

    首先我以爲有必要先把DDD中的經常使用名詞作一個解釋。

    界限上下文：表明一個系統、一個應用程序或者一種業務服務。限界上下文所包含的領域模型概念應該恰如其分，很少也很多。

    通用語言：做用於某個「限界上下文」，在一個特定的限界上下文中只使用一套通用語言，而且保證它的清晰性（避免一個概念在同一個界限上下文中的二義性）和簡潔性。舉個例子：像京東和天貓這樣的B2C系統中會用到系統的人有2種，買家和賣家，對於系統來講均可以稱爲用戶，可是這樣破壞了清晰性的特色。若是使用一個相似Type的枚舉來區分，破壞了簡潔性。因此對於這種場景，就應該直接設計2個對象：買家和賣家。    

    領域：從大了看，領域表明整個公司的運做一切。從小了看，是每一個組織運做中的一切。因此領域的概念必然與公司的組織架構所承擔的職責有必定的關係。

    子域：一個領域內能夠包含1個或者多個子域。理論上一個子域對應一個限界上下文是最優也是最理想的狀況，可是有時又要考慮到業務關聯度須要作出權衡。子域又分核心域、支撐子域、通用子域。

    核心域：它是整個業務領域的一部分，也是業務成功的主要促成因素。從戰略層面上講，企業應該在覈心域上勝人一籌。咱們應該給予核心域最高的優先級、最資深的領域專家和最優秀的開發團隊。在實施DDD的過程當中將主要關注核心域。

    支撐子域：對應着業務的某些重要方面，但卻不是核心，那麼它即是一個支撐子域。

    通用子域：某個支撐子域的運用範圍是整個系統，那麼這個子域即是通用子域。

    上下文映射圖：由多個界限上下文和子域組成的表示當前單個領域或者多個領域之間的集成關係圖。

 

3、實施DDD的關鍵

    我認爲實施DDD最最最關鍵的東西有2樣。

    一是「通用語言」，沒有基於通用語言創建的所謂的聚合，實體，值對象，只能算是DDDLite，只是技術層面的一種設計方式。

    二是「建模」，建模又分爲戰略建模和戰術建模，這2者相輔相成，來構建合理的上下文映射圖。

    ①戰略建模：戰略建模是以一種最宏觀的角度去審視整個項目對它進行拆分，來劃分「界限上下文」，最終造成一個具備俯瞰視角的「上下文映射圖」。

    ②戰術建模：在咱們戰略建模劃出的「界限上下文」中進行「聚合」、「實體」、「值對象」的建模，而且按模塊分組。

 

4、如何構建一個領域的上下文映射圖

    對於如何構建一個上下文映射圖，分爲思想和操做2個層面。

    首先思想層面須要引入2個空間的概念：問題空間和解決方案空間。

    在問題空間中，咱們思考的是業務所面臨的挑戰，而在解決方案空間中，咱們思考如何實現軟件以解決這些業務挑戰。    

    評估問題空間和解決方案空間的問題：

    ①這個戰略核心域的名字是什麼，它的目標是什麼？

    ②這個戰略核心域中包含哪些概念？

    ③這個核心域的支撐子域和通用子域是什麼？

    其次操做層面就是[Vaughn Vernon]《實現領域驅動設計》裏提到的9種組織模式和集成模式。

    ①合做關係（Partnership）：若是2個限界上下文的團隊要麼一塊兒成功，要麼一塊兒失敗，此時就是這種關係。應該爲相互關聯的軟件功能制定好計劃表，這樣能夠確保這些功能在同一個發佈中完成。

    ②共享內核（Shared Kernel）：對模型和代碼的共享將產生一種緊密的依賴性，對於設計來講，這種依賴性可好可壞。咱們須要爲共享的部分模型指定一個顯式邊界，並保持共享內核的小型化。共享內核具備特殊的狀態，在沒有與另外一個團隊協商的狀況下，這種狀態是不能改變的。咱們應該引入一種持續集成過程來保證共享內核與通用語言的一致性。【簡單的說就是數據庫共享】

    ③客戶方——供應方（Customer-Supplier Development）：當2個團隊處於一種上游——下游關係時，上游團隊可能獨立於下游團隊完成開發，此時下游團隊的開發可能會受到很大的影響。所以，在上游團隊的計劃中，咱們應該顧及到下游團隊的需求。

    ④遵奉者（Conformist）：在存在上游——下游關係的2個團隊中，若是上游團隊已經沒有動力提供下游團隊之需，下游團隊便孤軍無助了。處於利他主義，上游團隊可能向下遊團隊作出種種承諾，可是有很大的多是：這些承諾是沒法實現的。下游團隊只能盲目地使用上游團隊模型。

    ⑤防腐層（Anticorruption Layer）：在集成2個設計良好的限界上下文時，翻譯層可能很簡單，甚至能夠很優雅的實現。可是，當共享內核，合做關係或客戶方——供應方關係沒法順利實現時，此時的翻譯將變得複雜。對於下游客戶來講，你須要根據本身的領域模型建立一個單獨的層，該層做爲上游系統的委派向你的系統提供功能。防腐層經過已有的接口與其餘系統交互，而其餘系統只須要作很小的修改，甚至無需修改。在防腐層內部，它在你本身的模型和他方模型之間進行翻譯轉換。【爲每一個防腐層定義相應的領域服務】

    ⑥開放主機服務（Open Host Service）：定義一種協議，讓你的子系統經過該協議來訪問你的服務。而且須要將協議公開。

    ⑦發佈語言（Published Language）：在2個限界上下文之間翻譯模型須要一種公用的語言。此時你應該使用一種發佈出來的共享語言來完成集成交流。發佈語言一般與開放主機服務一塊兒使用。

    ⑧另謀他路（SeparateWay）：在肯定需求時，咱們應該作到堅持完全。若是2套功能沒有顯著的關係，那麼它們是能夠被徹底解耦的。集成老是昂貴的，有時帶給你的好處也不大。聲明2個限界上下文之間不存在任何關係，這樣使得開發者去另外尋找簡單的、專門的方法來解決問題。

    ⑨大泥球（Big Ball of Mud）：當咱們檢查已有系統時，常常會發現系統中存在混雜在一塊兒的模型，它們之間的邊界是很是模糊的。此時你應該爲整個系統繪製一個邊界，而後將其概括在大泥球範圍之列。在這個邊界內，不要試圖使用複雜的建模手段來化解問題。同時，這樣的系統有可能會向其餘系統蔓延，應該對此保持警覺。    

 

5、構建咱們的上下文映射圖

    本次的系列的主題是電商網站，那麼如今開始構建一個電商網站的上下文映射圖。

    ①這個戰略核心域的名字是什麼，它的目標是什麼？

    銷售核心域，目標是賣更多的商品，獲取更多的利潤。這點是整個組織的共同目標，因此應該很容易界定，而且應該是在整個組織中能最終夠達成一致的某個觀點。如圖1。

 

　　　　　　　　　　　　　　　　　　　　　　　　　　 【圖1，點擊圖片查看大圖】

    ②這個戰略核心域中包含哪些概念？

    我通常會使用「劃分」，「組合」，「梳理」的3步走方式去作。先根據咱們對這個領域的理解進行劃分出各個上下文，而後從新審視每一個上下文在銷售這個領域中的定位來「圈地（劃分子域）」，最後再思考是否可以徹底體現出每一個子域的功能和職責。個人思路是這樣的，先根據我本身的經驗得出了圖2。

    　　　　　　　　　　　　　　　　　　　　　　　　【圖2，點擊圖片查看大圖】

    我思考了一下，整個銷售過程當中，訂單只是一個結果，一旦到達這個環節，其實銷售的工做已經結束了，那麼訂單的相關業務其實不該該屬於銷售的子域內，因此把它拿出去，變爲圖3這個樣子。

    　　　　　　　　　　　　　　　　　　　　　　　　【圖3，點擊圖片查看大圖】

    而後看了一下全圖，銷售上下文的概念太泛，沒法得知其中應該幹什麼，怎麼去銷售，有哪些影響銷售概念，我又作了拆分。以下圖4。

    　　　　　　　　　　　　　　　　　　　　　　　　　　【圖4，點擊圖片查看大圖】

    到這裏幾個核心域內包含的概念已經出來了：價格體系（促銷、會員價）、銷售方式（打包、捆綁贈品）、內容管理、購買。這其中最核心的又是購買。    

    ③這個核心域的支撐子域和通用子域是什麼？

    這裏開始咱們須要對咱們整理出的各個上下文和子域結合起來，而且根據9種組織模式和集成模式表達出各上下文之間的關係。以下圖5。

   　　　　　　　　　　　　　　　　　　　　　　　　　　 【圖5，點擊圖片查看大圖】

    這裏的U和D分別表明UpStream和DownStream，表達出上下游關係，而且圖的位置也須要看出這點。另外OHS+PL = Open Host Service+Published Language，ACL = Anticorruption Layer。

 

    發現這裏的5個子域中，訂單和物流子域分別承擔着2個子域的下游支撐做用，那麼成爲了通用子域。

    最終這個問題的結果爲商品子域[支撐]、會員子域[支撐]、支付子域[支撐]、訂單子域[通用]、物流子域[通用]。

    最後再考慮到一些非必須的輔助性概念，數據分析系統和預測系統，造成咱們的最終上下文映射圖。

    　　　　　　　　　　　　　　　　　　　　　　　　　　【圖6，點擊圖片查看大圖】

 

6、結語

    以上的每一個環節都應該儘量有領域專家參與，這樣才能得出最符合實際的上下文映射圖。DDD之路很差走，而且從短時間的表面來看，須要花費的時間和精力會比咱們常規的數據驅動開發方式看上去多的多。可是從溝通的便捷性、理解的錯誤率、代碼的可維護性來看，DDD可以讓對項目的把控更上一個層級。而且爲了應對互聯網行業的快速變化，咱們獲得的遠比咱們付出的多的多。

    

做者：Zachary
出處：https://zacharyfan.com/archives/95.html

 

 

▶關於做者：張帆（Zachary，我的微信號：Zachary-ZF）。堅持用心打磨每一篇高質量原創。歡迎掃描右側的二維碼~。

按期發表原創內容：架構設計丨分佈式系統丨產品丨運營丨一些思考。

 

若是你是初級程序員，想提高但不知道如何下手。又或者作程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關注個人公衆號「跨界架構師」，回覆「技術」，送你一份我長期收集和整理的思惟導圖。

若是你是運營，面對不斷變化的市場一籌莫展。又或者想了解主流的運營策略，以豐富本身的「倉庫」。歡迎關注個人公衆號「跨界架構師」，回覆「運營」，送你一份我長期收集和整理的思惟導圖。