DDD中如何藉助行業術語突破性發現領域模型？ - Mathias

1. 瞭解問題，
2. 應用設計，
3. 最終得到一個解決方案。

領域語言與無處不在的統一語言
這個想法也一直存在於領域驅動設計的許多幼稚的解釋中。領域語言（行業術語）和無處不在的統一語言（Ubiquitous Language ）經常被混為一談。他們是不一樣的。
領域語言是在領域工作的人使用的語言。這是一種自然語言，因此很混亂。它是有機的：概念的引入是出於需要，沒有經過深思熟慮，沒有達成一致，沒有精確。術語在整個組織中傳播或逐漸消失。意義轉變。人們將舊術語改編成新含義，或者術語獲得了多重、含糊不清的含義。它存在是因為它有效，至少對於人與人之間的交流來說足夠好。領域語言（像所有語言一樣）只能在它進化的特定上下文中工作。
對於我們系統設計師來說，亂七八糟的語言是不夠的。我們需要具有易於理解的概念和明確上下文的精確語言。這就是無處不在的語言：一種構建的、形式化的語言，由利益相關者和設計師同意，以滿足我們的設計需求。與領域語言相比，我們需要更多地控制這種語言。統一語言必須和領域語言有很深的聯絡，否則就會出現不和諧。
任何通用語言的正式程度和精確度取決於其環境上下文：例如：共享應用程式和石油鑽井平臺控制系統有不同的需求。
 

石油鑽井平臺 
Rebecca 受邀為一家為石油鑽井平臺製造硬體和軟體的公司提供諮詢。她被要求幫助進行物件設計和建模，致力於重新設計監控和管理石油鑽井平臺上的感測器和裝置的控制系統。鑽孔會產生很大的摩擦，“鑽井泥漿”（一種專有化學物質）被用作潤滑劑。它還用作您從鑽孔中獲得的岩石和碎屑的載體，將它們全部提起並從孔中取出。裝置監測鑽井泥漿壓力，透過在鑽井過程中改變泥漿的成分，您可以控制該壓力。壓力太大真的是件壞事。
然後海灣中的一個石油鑽井平臺爆炸了。
隨著新聞報導的出現，該團隊發現該鑽機正在使用競爭對手的裝置。哇！團隊開始推測可能發生的事情，並考慮如何在他們自己的系統中發生類似的事情。是裝置、感測器、遙測、各種元件之間的通訊、軟體有問題嗎？
  

上下文場景情形
團隊研究了當時發生災難的場景。當災難性情況發生了什麼？人們如何反應？當出現故障時，對於石油鑽井平臺工程師來說，這是一個嘈雜的環境：警報器響起，警報響起，......儘管。當故障很容易修復時，控制系統日誌會反映警報持續發生並在幾分鐘後關閉。
但是對於更嚴重的故障，即使這些問題需要更長的時間來解決，它仍然會在日誌中顯示為在幾分鐘內解決。然後，當人們研究日誌時，看起來故障很快就解決了。但這完全不準確。這可能看起來像一個軟體錯誤，但它實際上是模型中的一個缺陷。我們應該利用它作為改進該模型的機會。
最初的建模假設是警報與現實中的緊急情況直接相關。然而，系統對世界的感知是扭曲的：當工程師關閉警報時，系統認為緊急情況已經結束。但事實並非如此，關閉警報並不會改變世界上的緊急情況。警報僅與緊急情況間接相關。如果它是間接連線的，則介於兩者之間的其他東西，在我們的模型中不存在。該模型是對世界事實的不完整表示，這可能是災難性的。
 
“向真正深度模型的過渡是你思維的一次深刻轉變，需要對設計進行重大改變。” —領域驅動設計，埃裡克·埃文斯
  

突破
團隊探索了一些場景情形，特別是奇怪的情形、尷尬的邊緣情況，沒有人真正知道系統的行為方式，甚至不知道它應該如何行為。一種這樣的場景情形是當兩個單獨的感測器測量同時發出警報時。警報響起，工程師將其關閉，但是第二個警報會發生什麼？警報是否仍應響起？應該關閉一個就關閉另一個警報？如果它沒有關閉，工程師會認為關閉開關不起作用並再次按下它嗎？
透過處理這些場景情形，該團隊發現警報響起和警覺狀態之間存在區別。現在，在這個新模型中，當感測器的測量值超過特定閾值或表現出特定模式時，系統不再直接發出警報。相反，它會引發警報條件，該條件也會被記錄。正是這種與實際問題相關的警報條件。新的警報概念現在負責發出警報（或不發出警報）。警報仍然可以關閉，但警報條件仍然存在。具有不同原因的兩種警報條件可以共存，而不會被單一警報混淆。該模型將緊急情況與警報聲分離。
舊模型沒有做出這種區分，因此它不能很好地處理邊緣情況。當團隊終於明白需要將警報條件與警報分開時，他們無法忽視它，這種區別並不容易被發現。這就是埃裡克·埃文斯所說的突破。
 

創造之舉
有一個缺失的概念，起初團隊不知道缺少什麼。起初並不明顯，因為在領域語言中（行業術語）沒有“警報條件”這個名稱。石油鑽井平臺工程師的工作不是設計軟體或建立精確的語言，他們只是希望能夠平靜地響應警報並解決問題。規範檔案或石油鑽井平臺工程師之間的任何通訊中也都沒有出現警報條件。工程師或軟體並未暗中使用該概念；不，整個概念不存在。
那麼這個概念是怎麼來的呢？
該領域的人遇到過這個問題，只是沒有明確的術語，他們無法向系統設計者表達這個問題。所以必須由我們設計師創造它。這是一種創造性的建模行為。這個概念是發明出來的。在我們的石油鑽井平臺監控領域，這是一種感知現實的新方法。
當然，在英語中，alert 和alarm 是存在的。它們幾乎是同義詞。但是在我們無處不在的語言中，我們同意讓它們與眾不同。我們設計了同意語言（ Ubiquitous Language） 來滿足我們的目的，它不同於領域語言這些行業術語。在我們引入“警報條件”之後，石油鑽井平臺工程師同意將其納入他們的語言中。

領域中的這種變化是由設計驅動的。這打破了透過設計從問題到解決方案的線性、單向理解。相反，透過設計，我們重新定義了問題。
 

它是一個更好的模型嗎？
我們怎麼知道這個新發明的模型實際上更好（具體來說，更適合目的）？我們找到現實場景並針對警報條件模型以及其他候選模型對其進行測試。在我們的例子中，使用新模型，日誌會更準確，這是原始最初問題爆發所在。
但除了有助於解決最初的問題之外，更深層次的模型通常會帶來新的可能性。該警報條件模型提出了幾個建議：

• 不同的測量可以與相同的警報相關聯。
• 警報條件可以被限定。
• 我們可以為同時出現的警報條件定義警報行為，例如透過間隔警報或選擇不同的聲音模式。
• 嚴重警報可以阻止不太重要的警報佔用警報。
• 隨著情況的改善，警報條件可以降低，而無需解決它們。
• …

設計創造新現實
在以現實世界為中心的設計檢視中，現實世界中只存在感測器和警報，而舊的軟體模型準確地反映了這一點。因此，這是一個準確的模型。包含警報的新模型並不比舊模型更“準確”，它不是來自現實世界，也不是更現實，也不是更“領域化”。但它更有用。與警報條件相比，感測器和警報是客觀的。某些事情是一種警報條件，因為在這種環境中，我們認為它應該是一種警報條件，這是主觀的。
該模型適用於領域，並能連線到它，但它不是一個單純的模型的問題域。它解決了我們更好地設想的上下文中的問題。該解決方案澄清了問題。只關注現實世界的建模會使我們對更好的選擇和創新視而不見。
在有關建模的文獻中很少討論這些將新概念創造性地引入模型中。軟體設計書籍談論將概念轉化為型別和資料結構，但如果概念還沒有呢？然而，形成區別，而不僅僅是抽象，可以幫助澄清模型。這些區別創造了機會。
該模型必須從根本上考慮其在解決問題中的效用。