如何使得軟體架構與業務模型相結合？ - VLINGO

商業軟體的最大問題之一是技術架構比領域模型獲得的提升會更多。

大多數領域模型都是普通的，並且可以由學校學生以比通常花費很少的成本來實現；然而，通常支援模型的軟體架構，通常是過度設計的。一個常見的吹噓是這樣的：“該架構每秒可以處理 10,000,000 多條訊息！” 但架構師無法證明這一點。

企業為它需要的東西付費，但得到它需要的東西以外的一切。因為傳統的程式設計師在發現架構模式和實現方面會獲得更具挑戰性和滿足感。而且這種架構模式往往是通用的，幾乎可以用於每個專案，多次實施相同的機制後，光彩就會消失，並尋求新機制的更大挑戰，而企業所需要的東西仍然太少。

似乎需要更好的管理或架構治理來防止此類涉足模糊的非功能性需求、結構、元件和技術。還有一種方法：可以使跨軟體系統的領域模型比通用架構更具挑戰性和吸引力。

使領域模型變得有趣，不僅僅如此，而實是引人入勝，可以探索：挑戰團隊通過實驗和基於發現的學習來追求業務創新。失敗的實驗並不是徹底的失敗，因為學習的目的是通向成功。將您的業務專家和開發人員團隊視為在“知識領域”（即他們的領域）內推動創新。

使用領域模型進行創新需要業務專家和開發人員共同探索和發現獨一無二的核心競爭力。

這種努力的必要條件是多次問幾個問題。這是可以使用的第一組問題，沒有特定的順序：

• 為什麼？
• 總是？
• 為什麼不？
• 你確定嗎？
• 立即地？

這迫使業務專家和開發人員不僅要達成共識，還要發現新的和更高階的理解。

在這一點上，模型可能反映了普通情況，或者可能更好一點，儘管它可能看起來比以前專案中的貧血模型好得多。毫無疑問，你仍然沒有學到足夠的知識。結果可能充其量反映瞭解決已知已知問題和圍繞先前已知未知問題的清晰度。所以可能還有相當多的未知數，不管你認不認識。

要進一步考慮這些問題。使用者可能會遇到他們不會報告的問題，因為他們無法想象更好的事情。為了首先防止這些情況，團隊必須挑戰他們的知識並拒絕接受平凡。以下是發現極端案例的第二組問題：

• 如果我們再往前走一兩步，我們會學到什麼？
• 根據當前模型，這裡可能會出現什麼問題？
• 使用者是否會陷入難以恢復的問題？
• 該模型能否通過使解決方案顯而易見來提供幫助？

通常，發現極端案例揭示了以以前未識別的方式使軟體更加優越的機會。即便如此，您也可能會錯過一些突破性的見解。那時，您必須採訪一系列使用者，以找出他們難以做到的事情。觀察也可以教會你很多東西。如果您看到軟體以意想不到的方式使用，它幾乎肯定會大聲疾呼缺少工作流程和更廣泛的業務流程。請注意這些並將它們作為首要任務解決。

不要從“錯誤”的決定中“預測”使用者，因為他們當前的決定可能是正確的事件，儘管較早的決定現在發生衝突。有一個業務流程潛伏著。此類情況必須通過深度學習來想象或檢測、探索、試驗並不斷重新發現。當獲得足夠的知識來理解問題和解決方案時，一定要展示一系列資料和一系列選項，以幫助使用者快速達成明智的解決方案。