DDD提出者Eric Evans承認不足,希望DDD語言不斷改進 - infoQ
領域驅動設計的作者埃裡克·埃文斯(Eric Evans)在前幾天Explore DDD上的主題演講中,邀請聽眾積極參與改進在建模和設計複雜系統時使用的語言。
埃文斯(Evans)承認,DDD中使用的一些基本術語行話,如“有界上下文”常常被誤解。由於個人的偏見,其他短語(例如“遺留軟體”)也會造成系統產生無生產力的結構。
在關於如何提出一些更清晰的語言建議時,他歡迎所有人都可以不同意他的意見(banq注:不能因為不同意他的觀點被定位為邪教,例如聚合一詞很多人認為不合適)。
只有透過一個活躍的社群,在富有爭議的辯論中,我們才能真正實現DDD成為一個真實,生動的思想體系的目標。
埃文斯(Evans)認為,在他的書出版15年後的今天,也許是時候採取一些措施來回歸基本面,然後有意識地邁出新的步伐了。重點步驟之一應該就是:解決因為有界上下文,子域和組織的共同對齊而引起的混亂。(banq注:子域屬於問題空間邊界內,組織針對問題空間會提出解決方案,有界上下文屬於解決方案空間內,問題、人組織和解決方案這三個空間的概念如何對映對應?是當前DDD最大問題)
在許多情況下,一個有界上下文可以與組織或團隊保持一致,也可以與子域保持一致。但是,大型公司以重組而聞名,導致業務流程和職責的變化。當這些重組發生時,軟體不會以與重組前相同的方式進行更改,因此功能的管理方式變得不清楚。以前一個組織的職責現在可能需要兩個小組協作才能以定義需求和優先順序。
埃文斯(Evans)將這與三足式比賽進行了比較(三個人將腿幫在一起的比賽),在三足式比賽中,成功需要參與者在速度和協調性之間找到平衡。不協調的團隊將會跌倒,而協調良好但行動緩慢的團隊將無法獲勝。
他承認DDD最近的復興是由於微服務的興起而引起的,他認為這是開始富有成效的對話的絕佳機會。埃文斯認為,有些人只是“跳上了微服務潮流”,“微服務是打破障礙的重量戰鬥之路,要看混亂中的機會。”
微服務和DDD的關係,經常重複的一個普遍的概念是:“微服務是有界上下文”,這是一種過分簡化。Evans描述了微服務系統中的四種有界上下文型別:
- 服務內部(的上下文)
- 服務的API(的上下文)
- 服務叢集(的上下文)
- 服務之間的互動(的上下文)
隨著上下文範圍在此列表中的增加,思考的型別必須從狹隘和專注轉變為廣泛的體系結構觀點。如果每個微服務都只是彼此各自定義一套自己的獨特的通用語言,然後再使用訊息在整個系統中進行微服務之間通訊,而沒有架構上的統一思考,那將導致徹底的混亂。(banq注:有界上下文定義了自己一套獨特的通用統一語言,但是微服務就是有界上下文,因此微服務其實也就是定義了一套自己獨特的語言,從業務術語行話到計算機語言都可能不同,但是這種不同必須能夠相互整合在一起,這需要架構上設計)
Evans還想重新設計人們談論舊系統的方式,並找到以更有效率的方式進行討論的方法。埃文斯經常使用花園的比喻。新建的花園具有很好的秩序感,但是夏末花園(舊系統)具有“成熟度”,這就是發現花園的價值所在。同樣,開發人員和架構師應以建立秩序為目標播種種子,但也應欣賞成熟系統中存在的混亂豐富性。
埃文斯(Evans)提出不僅僅是針對廣義的“傳統舊系統”,還提出了新的方法來對“成熟的環境”進行分類和描述。使用DDD技術,應該繪製出成熟系統的上下文,並繪製上下文之間的關係。透過識別成熟環境已經處理的無聊的例行職責,可以幫助從始至終地對抗本能,就像成熟的花園已經具有生產力一樣。埃文斯指出,反腐敗層是雙向的;反腐敗層是雙向的。它們保護舊系統中的新程式碼,並且還使舊系統不受新程式碼的影響。
當使用可能被描述為“泥濘大球”的程式碼時,重要的是要記住,並非系統的所有部分都會經過精心設計。一旦系統足夠大,您將無法回到整潔的世界。取而代之的是,爭取在良好邊界下實現的利益,並隔離整潔的環境。
相關文章
- 讀《實戰DDD(Domain-Driven Design領域驅動設計:Evans DDD)》想到的AI
- 使用函式式語言實踐DDD函式
- 領域本體與DDD的UL語言
- <實戰DDD(Domain-Driven Design領域驅動設計:Evans DDD)>讀後疑問AI
- DDD的函數語言程式設計實現函數程式設計
- DDD中限界上下文與通用語言的作用
- ddd
- OnionArch 2.0 - 基於DDD的洋蔥架構改進版開源架構
- 可落地的DDD(4)-如何利用DDD進行微服務的劃分(2)微服務
- DDD通用語言UL案例:醫保資訊業務編碼標準
- 如何理解DDD中的不變性,不變數變數
- 關於DDD,語言和主流架構架構
- 什麼是DDD領域驅動設計的統一語言?
- 從MVC到DDD的架構演進MVC架構
- 這就是為什麼你學不會DDD
- 幽默:神經科學的認知漸進模板用在DDD和微服務上微服務
- 通過語言的比喻句發現隱藏的DDD模型 - verraes模型
- ddd-crew/ddd-starter-modelling-process:DDD設計入門建模流程
- DDD與Repository
- DDD實踐反思
- 使用DDD澄清MVVMMVVM
- OO DDD應用!
- 如何實踐DDD?
- DDD 我的理解
- 當SOA遇到DDD
- DDD之1微服務設計為什麼選擇DDD微服務
- 實施DDD的幽默:DDD落地需要專門的框架嗎?框架
- 從壹開始微服務 [ DDD ] 之八 ║剪不斷理還亂的 值物件和Dto微服務物件
- 改進大語言模型的最全方法!模型
- Go語言封裝、繼承、介面、多型和斷言的案例Go封裝繼承多型
- DDD的戰術模式模式
- 什麼才是DDD框架?????框架
- DDD深思,物件裝備模型物件模型
- DDD的理解問題
- DDD應用場景
- DDD精粹速讀(一)
- DDD精粹速讀(二)
- Haters Gonna Hate (Eric Evans對NoSQL的冷靜看法)GoSQL