\\\\\
在2023年探索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的廣度、目標、它的用武之地以及在哪些場景中會用力過猛多需要有一定的了解。
\
檢視英文原文：ddd with tlc
領域驅動設計系列（一） 為何要領域驅動設計？
領域驅動設計最近貌似開始火起來了，越來越多的人開始認識到領域設計的重要性，從我做過的專案來看，似乎歐洲已經有很多的公司開始實施領域驅動設計了，我看領域驅動設計也有些時間了，但是網上不管是文章還是 都顯得太過 高大上 一談領域驅動設計，一大堆的概念一股腦的給你上上來，搞的有點暈頭轉向，而我想在一些中小...
領域驅動設計之我見 領域業務
談到領域驅動設計 ddd 人們很容易想到如下這張圖，那麼是不是你的軟體做了如下的分層設計就是領域驅動設計的了？顯然不是，以下分層只能說明的軟體做了分層架構，領域驅動設計的核心在領域模型，領域模型的核心在業務知識。如果能夠採用物件導向思維將業務抽象為恰當的模型，不管用什麼架構都稱得上領域驅動設計。在大...
領域驅動的設計 摘要
第1 章 汲取知識 第2 章 溝通和語言的使用 通用語言,大聲讀出模型,乙個團隊,一種語言 第3 章 將模型和實現相繫結 第4 章 分離出領域 分層架構,領域層中存放著模型 第5 章 模型在軟體中的表現形式 關聯,實體 也稱為引用物件 值物件,服務,模組 也稱為包 建模範型 第6 章 領域物件的生命...