“親切照料”下的領域驅動設計
\\\關鍵要點
\\
- 在將DDD引入新團隊時,請從有界的上下文開始——將大問題分解為可管理、可解決的小問題。撇開繁文縟節,動手去做。\\t
- 瞭解團隊成員的能力,以便能夠成功地指導他們,這與本能和同理心有很大關係。仔細聆聽、尊重、不評判、和善,這些都是非常重要的。\\t
- 人們抵制DDD,是因為他們認為DDD的內容太多了,或者會對他們當前的流程造成太大破壞。解決小問題是可以幫助人們獲得對DDD信任的一種很好的方式。\\t
- 領域建模是一門藝術,而不是一門科學,因此,出現碰壁或突然改變方向的情況並不罕見。團隊需要一個熟悉建模的教練,讓你在整個過程中無需擔心視角的變化。\
在2017年探索DDD會議上,Serial DDD倡導者Julie Lerman談到了如何通過“親切照料”進行領域驅動設計。InfoQ採訪了Lerman,談論了她如何向新客戶介紹DDD並幫助他們取得成功。
\\InfoQ:大多數DDD從業者都記得他們是如何首次引入域驅動設計的。你的DDD起源故事是怎樣的?
\\\\\Julie Lerman:不管你信不信,我必須感謝Jimmy Nilsson!多年前,當微軟釋出LINQ和Entity Framework時,發生了一些爭議。我和Jimmy Nilsson在InfoQ上接受了一次採訪,他被問到他對LINQ和Entity Framework的看法——這是我非常感興趣的一個觀點。在採訪結束時,Jimmy被問到一個問題:“你最喜歡的書是什麼?”他回答是Eric Evans的《領域驅動設計》,Jimmy說它讀起來就像詩歌一樣。那時我正在為O’Reilly Press寫一本關於Entity Framework的書。這是我的第一本書,我真的很想知道讓一本科技圖書讀起來像詩歌的意味著什麼。所以我拿起了Eric的書,書中涉及的第一個討論話題是關於領域專家參與度的重要性——這對我在客戶方面取得的成功來說至關重要。我喜歡瞭解他們的業務,並與我的很多客戶建立了長期穩固的關係。
\
InfoQ:DDD涵蓋了很多主題。當你開始與新團隊合作時,你是如何引入DDD的,以及如何避免向其他人灌輸太多新概念?在這方面是否存在一些教學技巧?
\\\\\Lerman:我通常是在他們正在重構或更換遺留應用程式或正在開發應用程式時加入他們的,而且我只在那裡短暫停留,所以我會盡可能快儘可能多地讓他們接受DDD。我從有界的上下文開始——將他們的大問題分解為可管理可解決的小問題。我甚至在一開始都沒有使用術語。然後我從鬆散的有界上下文中選擇一個簡單的目標,並分析它,然後識別出領域模型的不同部分——一次一個,而不是一次性完成。我在一開始就使用新概念,不擔心術語問題。從我個人的經驗來看,大腦會被術語鎖定。所以,我找到了更簡單的方法引入新主題——更加明顯的類比方式。最後,我再把術語新增進去……聚合、聚合根等,並向他們解釋使用這些術語的重要性,這樣每個人都可以達成共識。對於無所不在的語言來說,這也是一個很好的選擇!
\
InfoQ:Evan那本書的副標題是“解決軟體核心的複雜性”。康威定律意味著複雜的應用程式通常需要複雜的組織和團隊來支援它們。DDD的概念,例如有界上下文,是否有助於理解和指導團隊?
\\\\\Lerman:瞭解團隊成員的能力,以便能夠成功地指導他們,這與本能和同理心有很大關係。仔細聆聽、尊重、不評判、和善,這些都是非常重要的。但是,我也很依賴直覺和經驗來“讀取房間”。我的星座是天秤座,所以我的性格主要關於平衡和調解。當我與團隊合作,並且需要以積極的方式繼續前進時,對我的客戶有很大的幫助。我認為這與DDD人性的一面很有關係——與客戶密切合作以瞭解他們的業務,識別他們的問題並獲得他們對你的信任,最後解決所有的問題。這就是最初Eric的書吸引我的原因。DDD的技術或戰術設計部分只是錦上添花!
\
InfoQ:你有聽到哪些反對採用DDD的爭論?你是如何回應他們的?
\\\\\Lerman:有一些觀點認為DDD需要學習的東西太多了,這會對我們的流程造成太大破壞,因為需要太多的重新思考、重構和時間。
\\我回到了“解決小問題”的方法——尋找機會通過小投入獲得大利益。
\
InfoQ:如果你只有兩三天的時間來引入DDD和指導團隊,你會怎麼做?你的目標是什麼,以及如何優化時間以最大化實現這些目標?
\\\\\Lerman:我首先會想知道他們在做什麼,他們的目標是什麼以及他們擔心什麼——顯然是某種東西,否則他們就不需要我加入。然後我就開始進行神奇的“把大問題分解成小問題“,從這些問題中挑選一些解決方案,然後對其進行建模。我最常幫助他們進行遺留系統的替換,我們在白板上進行建模。建模是一門藝術,而不是一門科學,因此,因此,出現碰壁或突然改變方向的情況並不罕見。對於那些熟悉建模並且在整個過程中不擔心視角變化的人來說,體驗這一點對他們有好處。我出於同樣的原因在那裡做一些群體程式設計。我很清楚我們可能會遇到哪些技術問題,因此我可以指導他們完成。
\
InfoQ:對於試圖開始使用DDD的人,你有什麼建議嗎?
\\\\\Lerman:很多人通過專注於技術軟體實現(稱為戰術設計)開始他們的DDD之旅,戰略設計對於DDD來說至關重要,並且當你與領域專家合作,瞭解他們的領域和計劃你的系統的時候,戰略設計應該是放在第一位的。確保自己至少對DDD的廣度、目標、它的用武之地以及在哪些場景中會用力過猛多需要有一定的瞭解。
\
關於受訪者
\\Julie Lerman 是微軟區域總監和微軟MVP。她主要從事全球軟體團隊的軟體教練和顧問方面的工作。你可以在世界各地的使用者組和大會上看到Lerman呈現的有關Entity Framework、域驅動設計和其他有趣的主題。Lerman在thedatafarm.com/blog上發表博文,是備受好評的“Programming Entity Framework”一書的作者、MSDN雜誌Data Points專欄作者和Pluralsight.com熱門視訊的作者。
\\檢視英文原文:DDD With TLC
相關文章
- DDD領域驅動設計:領域事件事件
- MasaFramework -- 領域驅動設計Framework
- 領域驅動設計示例
- 理解領域驅動設計
- JavaScript中的領域驅動設計JavaScript
- 戲說領域驅動設計(廿五)——領域事件事件
- 領域驅動設計戰術模式--領域事件模式事件
- 領域驅動設計核心概念
- 領域驅動設計簡介
- DDD領域驅動設計pdf
- 再談領域驅動設計
- 實現領域驅動設計
- 整潔的領域驅動設計 - George
- 問題驅動設計與領域驅動設計的區別 - abdullin
- 戲說領域驅動設計(廿一)——領域服務
- 領域驅動設計戰術模式--領域服務模式
- DDD-領域驅動設計示例
- 微服務領域驅動設計 - semaphoreci微服務
- 淺談DDD(領域驅動設計)
- 淺談 DDD 領域驅動設計
- 何時使用領域驅動設計
- DDD領域驅動設計:倉儲
- 前端開發-領域驅動設計前端
- 戲說領域驅動設計(五)——子域
- 領域驅動設計對依賴的控制
- 領域驅動設計中的異常 - Michał
- 領域驅動設計的DDD與ddd - nick
- 領域驅動設計的概念解釋 -DEVdev
- 最常見領域驅動設計錯誤
- 領域驅動設計整合與架構架構
- dayatang/dddlib:DDD領域驅動設計庫
- 戲說領域驅動設計(廿二)——聚合
- 戲說領域驅動設計(三)——困境
- DDD-領域驅動設計簡談
- 領域驅動設計(DDD)入門&概要
- 戲說領域驅動設計(二)——修身
- 領域驅動設計 (DDD) 簡介 - jannikwempe
- 戲說領域驅動設計(廿七)——Saga設計模型模型