領域驅動設計（DDD）中模型的重要性 - Jeronimo

最重要的是領域
首先從DDD引起我注意的是用於實施模型的推薦設計模式集：值物件，實體，服務，工廠，儲存庫等。模式是具有悠久傳統並在行業中得到整合的工具（GOF，Martin Fowler，Eric Freeman等）。以前的經驗使我認為這些模式正是DDD的最大貢獻，但是我錯了。 
與DDD真正相關的是，強烈要求將Domain作為軟體開發的真實來源。每當您認為自己偏離正確的道路時，都必須回到原點。例如，當您不確定要開發的功能的價值時，或者懷疑使用大炮殺死蒼蠅時（過度設計）。有必要學習使該域始終可見，並質疑不適合該域的所有事物的價值。
“對任何領域未涵蓋的開發提出質疑是領域驅動設計的主要課程”

我們如何指定領域？
透過模型指定領域。模型是一組工件（圖表，文件，原型等），其中包含域的有意義的表示形式。這是業務掌握和技術設計之間的中間步驟。特點：

1. 無處不在統一語言（“通用語言”）。對於業務和技術，它必須是可理解的且有意義的。所有團隊成員（包括業務人員）在其交流中都使用模型的術語：使用者故事，用例，功能，任務等。 
2. 它們是軟體設計的基礎和一面鏡子。開發團隊使用該模型來建立實現該模型的設計。而且，它將在專案的整個生命週期內使設計和模型保持同步。設計中的任何更改都必須根據模型進行驗證。如果由於開發而認為必須對模型進行調整，則需要與業務部門一起審查變更並以通用語言執行變更。 

模型的闡述
在DDD中，模型將透過兩種力量誕生和發展：業務與開發。兩種觀點都必須從一開始就參與其建立。開發團隊應該將模型視為工作的另一產品，理解模型如何幫助您建立更好的解決方案，併為模型的質量和程式碼的質量感到自豪。 
將模型的建立或維護委派給團隊外部的分析師根本行不通。團隊必須在沒有中介的情況下參與領域分析和建模的認知工作。這是維持敏捷過程並確保團隊參與其維護的唯一方法。
 

建模工具
我已經是這個行業的資深人士。我經歷了像RUP這樣繁重的過程。系統地使用建模工件在階段之間進行通訊。當我擔任業務分析師或設計師時，我廣泛使用UML和BPMN。後來，在所有敏捷運動（尤其是XP）中，我都避免使用這些工具，其原則是程式碼應該是不言自明的。一如既往，保持平衡是美德。
建模工具（尤其是UML）對於為所有參與者建立有意義的框架非常有用。企業很難理解該程式碼。甚至使用專門改編的框架使它們更具表現力，例如“ 領域特定語言”。 
程式碼對於設計而言可能就足夠了。按照模組和元件進行組織，分配職責的一致策略以及統一的命名慣例應使設計顯而易見。 
您可以依靠具有許多IDE的程式碼分析工具來建立帶有軟體中存在的實體和依賴關係的圖。這有助於理解設計並針對模型進行驗證。分析圖具有短暫的優勢，我們無需花費過多成本即可建立和丟棄它們，因此我們不必對其進行管理。沒有設計文件會阻止它取代程式碼所反映的事實。 
使用UML時要小心。這是一個非常通用的工具。模型絕不應包含諸如繼承，封裝或特定型別之類的細節。我之所以這麼說並不是因為模型必須與實現技術無關（我們很少在專案中尋找它），而是因為它失去了設計的中間步驟的作用。請記住，它是用於與業務進行交流並指導開發的抽象。 
不斷避免在模型上編寫設計細節確實是一個苦難。但這正是DDD的目標。強制所有對話者使用與普遍存在的語言相容的抽象級別。 

模型管理
我與喜歡手工建立模型（帶有標記）的同事一起工作。主要論點是，它們以始終“正在建設中”的腳手架之類工件反映了企業不斷變化的性質。
對我來說很麻煩。如果我們使用黑板，則會不小心將其擦掉。如果我們使用紙張，則紙張會很快被圈圈圖填充，並且清潔所花的時間要多於製造時間。在這兩種情況下，資訊都難以共享。 
我更喜歡數字格式。我使用了諸如Visual Paradigm或ArgoUM L之類的專用工具。我知道它們給我的一切以及我剩下的一切。這就是為什麼在許多情況下，我更喜歡使用較輕的工具來鍵入圖表的原因。Draw.io非常適合中小型專案。但是，我一直在審查可用的工具。如果您使用的是最適合自己的產品，請在評論中註明。 

結論：觀看模型
域驅動設計是一種涉及從業務到模型以及從模型到軟體的兩種轉換的技術。
模型在確保軟體與其必須代表的業務之間的對應關係中起著核心作用。該模型必須始終存在於多學科團隊的思想，計算機和黑板上。我們尋求一種“模型警察”的心態，以追尋與此通訊一致性的任何偏差。