2017首屆領域驅動技術大會一直是我非常期望的，要非常感謝右軍贈送的門票能夠讓我領略大會風采。
這屆大會組織者非常用心，組織了非常多的話題可供**，確實大會的內容給我帶來的感覺是震撼的，我之前對領域的了解也僅從《領域驅動設計》以及《實現領域驅動設計》這兩本書中有過學習，以及在實現微服務生態體系的過程中有過一些接觸。
在大會的整個程序中，聽了很多老師不同主題的演講，讓我印象極為深刻的還是：張逸老師的《bounded context的實踐意義》、騰雲老師的《ddd-沒那麼難》。下面我將分別結合這二個議題談談我自己的一些想法。
bounded context（限界上下文）的實踐意義（因為光線和距離的原因**可能不清晰，望大家見諒）
首先我們先來解釋一下，什麼是限界上下文。
《實現領域驅動設計》這本書中解釋到：限界上下文是乙個顯式邊界，領域模型便存在於邊界之內。在邊界內，通用語言中的所有術語和片語都有特定的含義，而模型需要準確地反映通用語言。
用一段更形象的語言來描述：我們每天都去上班，上班的時候會換乘地鐵，我從8號線下車，換乘2號線，然後再去換乘10號線，這樣最終到達某乙個地點，結束上班這個過程。在這個過程中，8號線、2號線和10號線都可以理解為不同的限界上下文，我們中間換乘的動作可以理解為領域事件，而我們最終的目標是為了上班，這個就是關鍵事件，我們上班就是在不同的上下文中切換。
我們還可以把上下文理解為乙個模組，乙個系統、乙個應用或者乙個服務。在我看來，限界上下文的存在對微服務的劃分是有重大意義的，但是限界上下文不是新的概念，早在soa時代就已經存在，只是當時在企業應用的時候並沒有將soa和ddd過多的聯絡在一起，不知道還有多少同學知道板橋裡人（彭晨陽）的，早在2023年的時候在他的json**中就已經對soa和ddd的關係做過一些解釋：
soa服務是在松耦合元件分離後的再次打包，而evans ddd則是一把切斷元件關係的利刃。從這個方面看，ddd應該是更基礎平台，萬丈高樓平地起啊，而ddd是物件方**集大成，集合分析模式和設計模式通過當時的文章和解釋我們不難看出實際上在soa中更多的是使用ddd的oo來取代資料庫分析設計，soa是粗粒度的服務化打包，而ddd則是一把斬斷粗粒度的利刃。正如這次大會張逸老師一句玩笑的話所說，正因為微服務拯救了ddd，通過這句話可以看出微服務的提出是真正的將ddd給與結合在了一起，而微服務的細粒度的服務與ddd本身的理念也是契合，從而達到了互相發展的境界。—-出自 soa 與 ddd
ddd-沒那麼難資料驅動
領域驅動
資料庫優先
領域模型優先
演算法和資料機械結合
演算法和資料有機結合
技術導向
業務導向
**不能反映業務
**即是設計
業務邏輯分散
業務邏輯內聚
擴充套件性差
擴充套件性佳
我記得在2023年以前，研發人員和產品聊完需求後第一步就是要使用powerdesigner畫資料庫表結構圖，根據資料庫表結構圖倒推專案架構，後面ddd開始推廣以來，慢慢的由uml圖開始逐漸占用主導地位，現在表結構圖已經成為架構設計的補充。
在ddd中常見二種設計模型，分別是貧血模型和充血模型。
從圖中可以看出領域層的職責很弱，領域物件只是用來充當資料儲存的物件。但是這種模型整體架構清晰，自上而下單向連線。
這種模型的呼叫關係則變成了：遠端訪問介面 -> facade介面 -> service服務 -> 領域層 -> dao -> 資料庫應用層 -> facade介面 -> 領域層 -> 基礎設施層其實這樣的好處就是與領域物件相當的業務邏輯封裝在物件內部，biz或者service層只需要呼叫物件進行簡單的業務組裝即可，不像貧血模型那樣所有業務都集中在biz層或者service層中造成非常沉重難以拆分，但充血模型比較難以設計，需要有一定經驗的設計師前期規劃好，後期工作才能事半功倍，不然則會造成專案混亂。在分享中騰雲老師還做了實體和值物件的講解，下面我將這二者的區別以**的方式列出來供參考：
實體值物件
具有生命週期
起描述作用
有唯一標識
無唯一標識
通過id判斷相等性
實現equals方法
增刪改查/持久化
即時建立用完就扔
可變不可變
比如order/car
比如address/color
看到這裡讓我突然想起乙個故事來：
有一對雙胞胎，他們出生的時候，長得一模一樣，以至於爸媽都分不清，不得已他們在雙胞胎的脖子上繫個項鍊來標記：誰是老大？誰是老二？其實這個「標記」就可以看作是實體的標識，只不過是用項鍊來標識的。
有一天小鎮要統計雙胞胎的分布情況，然後調查人員來到他們家，問他們爸媽：「你們家裡有沒有雙胞胎？幾對雙胞胎？龍鳳胎？還是。。。」，然後他們爸媽就報上：「一對雙胞胎－兩個小子」，然後調查人員就做了筆記走了。在這個過程中，他們絲毫沒有提及雙胞胎脖子上的「項鍊」。
這也就是實體和值物件的根本區別：實體不僅需要知道它是什麼？而且還需要知道它是哪個？而值物件只需要知道它是什麼就可以了。
小結參考文章領域驅動設計之我見 領域業務
談到領域驅動設計 ddd 人們很容易想到如下這張圖，那麼是不是你的軟體做了如下的分層設計就是領域驅動設計的了？顯然不是，以下分層只能說明的軟體做了分層架構，領域驅動設計的核心在領域模型，領域模型的核心在業務知識。如果能夠採用物件導向思維將業務抽象為恰當的模型，不管用什麼架構都稱得上領域驅動設計。在大...
領域驅動設計系列（一） 為何要領域驅動設計？
領域驅動設計最近貌似開始火起來了，越來越多的人開始認識到領域設計的重要性，從我做過的專案來看，似乎歐洲已經有很多的公司開始實施領域驅動設計了，我看領域驅動設計也有些時間了，但是網上不管是文章還是 都顯得太過 高大上 一談領域驅動設計，一大堆的概念一股腦的給你上上來，搞的有點暈頭轉向，而我想在一些中小...
領域驅動設計 Understanding DDD
無論有沒有軟體支援,無論軟體是好是壞,世界各地每個領域每天都發生著數以億計可以理解的業務 領域驅動設計是一種設計方法,試 決的問題是軟體的難以理解,難以演化.採用的方法是圍繞業務概念來構建模型.不過你也可以從兩個角度來理解領域驅動設計 作為設計結果的ddd和作為開發方法的ddd,即 what and...