Share Pie: 隱藏的DDD寶藏 -Nick

解道jdon 2021-08-15 12:16:13 阅读数:610

本文一共[544]字,预计阅读时长:1分钟~
share pie ddd nick

領域驅動設計的一個方面很少被提及。我認為這是 DDD 最重要的方面,但是如果您在網上搜索“領域驅動設計”,您將找不到它。

這件寶物一直隱藏在人們的視線中。這是 Eric Evans 的 DDD 書第 8 章中的 Share Pie 故事。(Share Pie是一種投資組合策略,類似一個餡餅或餅圖,具體組成由百分比構成)

對我來說,這個故事就是 DDD 的真正意義所在:培養建模者的設計思維,以推動產品創新並實現價值的持續交付,涉及與領域專家的頻繁合作。

這也是一個很棒的故事,我從不厭倦重讀,並提醒我為什麼喜歡 DDD。

 

案例起因

在DDD一書第 8 章“突破”中,您很快就會感覺到埃裏克正在為史詩般的事情做准備。任何以“經過漫長的紐約重構冬天”開頭的故事都一定會讓 DDD 愛好者興奮不已:

經過紐約漫長的重構冬天,我們得到了一個模型,該模型捕獲了該領域的一些關鍵知識,並為應用程序做了一些實際工作的設計。我們正在開發一個大型應用程序的核心部分,用於管理一家投資銀行的銀團貸款。

這聽起來像是一個挑戰,但盡管如此,他還是對他們冬季工作的結果感到滿意。然後他通過告訴我們機會的規模(以及一點點名聲)來引起我們的注意:

當英特爾想要建造一座價值 10 億美元的工廠時,他們需要一筆巨額的貸款(需要融資),任何一家貸款公司都無法承擔,因此貸款人組成了一個財團,集中其資源來支持一項設施。投資銀行通常充當辛迪加領導者,協調交易和其他服務。我們的項目是構建軟件來跟踪和支持整個過程。

 

遭遇問題

然後我們確切地了解到他在紐約漫長的重構冬天意味著什麼——收拾別人的爛攤子。但至少現在他們處於一個很好的比特置。

我們感覺很好。四個月前,我們遇到了一個完全不可行的、繼承的代碼庫的大麻煩,此後我們一直在努力實現一個連貫的模型驅動設計。

但隨後故事發生了轉折。畢竟他們不是在這麼好的地方。他們處於我們在某個時刻都發現自己所處的艱難境地:八二發展。實現快樂路徑相對容易,實現所有其他要求帶來了更加複雜的挑戰。

但也有一些令人不安的迹象。我們不斷遇到使設計複雜化的意外需求。一個主要的例子是人們逐漸認識到,融資Facility中的份額只是一個指導方針……

Eric 和他的團隊知道代碼的日益複雜將成為一個關鍵問題。更重要的是,作為熟練的建模者,他們能够感覺到他們對該領域的概念性理解可能存在缺陷。

我們開始懷疑我們的困難是基本設計問題的征兆。

 

 

融資和貸款兩個概念傻傻分不清楚

然後故事發生了積極的轉折。Eric 和他的團隊在他們的理解和模型中找出了根本問題。

突然一個星期,我們意識到出了什麼問題。我們的模型以一種不適合業務的方式將 Facility融資 和 Loan貸款 份額聯系在一起。

他們在白板上與領域專家合作設計他們的新模型,並通過具體場景來驗證模型。

在業務專家點頭、熱情幫助的情况下……我們在白板上計算出一個新模型……我們使用新模型的可視化處理了許多場景

 

我知道 Eric 是現實生活中具體用例的忠實粉絲。他喜歡證明他的模型在現實中確實有效。在 Share Pie 故事中,他通過分享一個具體示例向我們展示了這一點(以下只是完整示例的一小部分):

該圖錶顯示,借款人已選擇從融資項下承諾的100萬美元中提取最初的50萬美元。這三家出借機構按照融資份額的確切比例分攤其股份,從而在出借機構之間分配了50萬美元的貸款…

再次展示他們的建模專業知識,Eric 和他的團隊能够准確地思考為什麼舊模型不起作用以及產生更好模型的關鍵是什麼。他們偶然發現了共享的領域概念。

我們有兩個深刻的見解。首先是意識到我們的“投資”和“貸款投資”中,是有通用概念和基本概念的區別:份額、融資份額,貸款份額、付款份額。

這種新見解確實轉化為積極的建模突破。他們的基本設計問題已得到强調。

突然間,在這種看待領域的新方式的基礎上,我們可以相對輕松地完成我們遇到的每一個場景,比以往任何時候都更簡單。

 

重構不是銀彈 

但隨後故事發生了下滑。

我們的新模型運行良好。真的,真的很好。

我們都覺得惡心!

我們面臨著嚴峻的最後期限;該項目已經危險地落後於計劃。

這個老問題讓 Eric 和他的團隊在不需要的時候拜訪了他們:有一個項目截止日期。更糟糕的是,他們沒有能力迭代新模型。需要大修(注意:不是通常意義上代碼重構,二是領域模型重構,模型重構其實意味著大部分重寫,banq認為這裏只是為了維護refactor這個詞語的尊嚴,其實就是重寫!):

重構的福音是你總是小步走,總是保持一切正常。但是將我們的代碼重構為這個新模型需要更改大量支持代碼,並且中間幾乎沒有穩定的停止點。

Eric 和他的團隊與他們的項目經理會面。Eric 解釋說,模型·重構會增加短期風險,但會降低長期風險。項目經理同意保護 Eric 和團隊,從而英勇地成為故事中的好人。

他同意了我們,並告訴我們他會處理高溫。我一直非常欽佩他做出這個决定所需要的勇氣和信任。

隨著故事接近尾聲,故事繼續回到積極的軌道上。Eric 和他的團隊的勇敢决定現在對業務層面產生了重大影響。他們開發的share pie(份額餅圖)概念已成為核心產品概念,甚至被營銷團隊與客戶使用。

這個 Share Pie 成為整個應用程序的統一主題。技術人員和業務專家用它來討論系統。營銷人員用它來向潜在客戶解釋這些功能。

在本章的結束討論中,Eric 强調了模型突破的另一個重要價值——它們為更多的建模突破奠定了基礎。

在軟件的 Share Pie 版本發布幾周後,我們注意到該模型的另一個尷尬方面使設計複雜化

Eric 然後通過隨意地提醒我們為什麼這個故事和 DDD 的含義對每個軟件專業人士都很重要來結束本章。

我們的開放步伐正試圖加快,而此時大多數項目正開始陷入已建成項目的大規模和複雜性之中。

 

分析share pie故事

我喜歡 Share Pie 的故事,我發現我們可以從中學到多少關於設計、建模和 DDD 的重要課程,這很有趣。我希望你也喜歡我的亮點,但我仍然建議閱讀書中的整個故事。

  • 現代產品主導型組織

這個故事已有 20 年的曆史,但仍然為今天的優秀產品團隊設定了標准。軟件工程師不是將需求翻譯成軟件的打字員。軟件工程師致力於設計他們正在構建的產品和功能。

Eric 和他的開發團隊與他們的領域專家合作發明了 Share Pie 的概念,該概念成為重要的產品和營銷功能。

(banq:這說明程序員已經介入了產品經理的職責範圍:以產品設計思維解决問題的好處 

  • 領域設計師

Share Pie 是一個新的領域概念。Eric 和他的團隊不僅僅是模擬物理世界中已經存在的東西。他們正在設計和發展領域的各個部分。

這可能是 DDD 中最容易被誤解的部分之一。DDD 是關於設計領域以及對其現有部分進行建模。創新是發明新思想、新領域概念和新領域術語。

(banq注:領域設計不是被動的分析需求,承接演繹需求,而是對需求進行幹預,這裏涉及到問題空間和解决方案空間,DDD不只是屬於解决方案空間,而會涉及道問題空間重新看待的問題:DDD中問題空間和解决方案空間是一個偽命題

  • 超越幸福之路

8/2規則在這個故事中很明顯。Eric 和他的團隊已經構建了一個適合所有常見用例的初始模型,但真正的艱苦工作開始嘗試實現所有其他用例。

作為一名工程師,如果一個模型看起來很簡單,請始終提醒自己在它使您眼花繚亂之前繼續尋找任何隱藏的複雜性。

(banq:這類似機器學習的算法模型和數據樣本之間的關系,在測試樣本下你的模型是正確的,但是到了生產數據樣本上,算法模型准確率大幅度下降,問題還是出在你的算法模型只覆蓋了八二法則中的八,那20%你沒有考慮到)

  • 在複雜性變得松散之前退後一步

當 Eric 的團隊看到代碼變得越來越複雜時,他們將每個新功能融入原始模型中,他們必須做出一個重大决定:繼續修改內容還是退後一步並嘗試重新設計模型?(banq:繼續小修小補屬於重構refactor,而重新設計核心業務模型,等於代碼重寫!這兩種區別類似對抗新冠病毒的方式:步步為營的控制與就地躺平的群體免疫。)

這可能是阻止代碼庫在接下來的 10 年中成為無法維護的混亂的决定。

在代碼庫中工作時,我們都會面臨這些决定。如果我們在複雜性失控之前投資我們的模型,我們可以保持我們的代碼健康且更易於使用。但是我們需要建模和設計技能來做到這一點。

  • 使用具體綁定的上下文場景驗證模型

當人們說 DDD 是學術和純粹主義者時,我知道他們還沒有接觸過真正的 DDD。如果您遇到過 Eric,您會很快了解到他致力於為具體場景建模,而不僅僅是使用抽象模型。

在 Share Pie 故事中,Eric 的團隊在白板上與領域專家一起繪制具體用例以驗證他們的新模型。如果你讀過這本書,你會發現這個場景非常詳細,插入了實數和事件序列,使其盡可能真實。

  • 為樂趣和利潤建模

這個故事中的所有成功事件都圍繞著模型的變化,這些變化要麼直接帶來業務收益,例如share pie,要麼間接地加快添加新功能的速度。

雖然 Eric 確實喜歡建模並從中獲得樂趣(並且也承受著很大的壓力),但他的樂趣來自於制作對業務有用的東西,而不是創建可以向學術朋友炫耀的漂亮模型。

  • 連續建模

在這個故事中沒有特別强調的主題之一是建模的不變性(持續一致性)。如果您不是每周都在自己的領域中發明像 Share Pie 這樣的概念,請不要感到羞耻,因為這些突破發生的頻率要低得多。

使 Share Pie 取得重大突破的是團隊每天進行的許多小模型重構。這些與領域相關的小改動(如重命名和提取部分代碼)的成本非常小,應該成為每個專業開發人員的好習慣。

(banq:這是持續一致做一件事帶來的複利湧現,滴水穿石,100個大道至簡的真相

  • 模型符合現實

沒有一個糟糕的截止日期,沒有一個關於軟件開發的故事是完整的,這個截止日期會使整個項目處於危險之中並讓每個人都感到壓力(盡管我們真的不應該美化這一點)。

在這個故事中,工程師和項目經理决定大膽地花時間改進模型,冒著錯過最後期限的風險。這肯定需要很大的勇氣,但這不是為了更好的模型吹噓自己的權利,而是為了降低項目的長期風險。

有時,即使功能延遲,我們也需要大膽投資於模型。在其他情况下,我們需要接受我們的模型是混亂的,但改進它的努力是不合理的。

DDD 並不是優先考慮建模而不考慮交付的借口,而是挑戰那種以犧牲長期可持續性為代價過度關注短期的借口。(DDD是克服短視的)

  • 戰術模式是額外的,而不是主要角色

Share Pie 故事中很少提及實體、聚合和值對象。簡要提及它們是為了更清楚地解釋 Share Pie 模型。

這是對 DDD 本身的一個很好的反思。戰術模式在創建和描述模型時很有用,但它們不應成為關注的中心。在教授 DDD 時,我們應該盡量避免在不教授建模價值的情况下教授戰術模式。

 

讓戰略設計成為DDD建模的十年:一個精心設計和進化的領域模型可以從產品創新和更易於理解和更改的代碼中提供許多好處。我的願望是,下一個十年的軟件開發將重新發現設計的價值,而 DDD 社區將更加强調真實建模和建模突破。

 

版权声明:本文为[解道jdon]所创,转载请带上原文链接,感谢。 https://gsmany.com/2021/08/20210815121613011h.html