使用業務能力方法實現DDD戰略建模 - pulse

將大型複雜系統模組化為更小、更易於管理的部分是很好的最佳實踐，不僅可以降低每個部分的認知負擔，還可以實現團隊獨立性和操作彈性。

棘手的一點是如何劃定邊界？為整個系統建立一個穩定和可持續的結構。基於有界上下文的領域驅動設計是一種方法，其中是使用領域語言作為指導，另一種方法是從業務模型定義的能力中汲取靈感，以找到領域中的自然接縫。

“業務能力是企業為實現特定目的或結果而可能擁有或交換的特定能力。” ——烏爾裡希·霍曼

什麼是業務能力

業務能力模型在企業架構中經常用作以整體方式描述公司的一種方式，代表獨立於結構、流程、人員或資源，如 IT 系統、建築、材料、硬體、工具等。一切都包括在內，每個螺母和螺栓；沒有任何東西屬於模型之外，它的前提是公司的由外而內的視角，因為它嚴格描述了公司的能力——它的賦能能力。

業務能力建模與 公司基於資源的檢視相關 ，通常被視為對它的擴充套件，因為它也支援 經典價值鏈之外的其他 價值配置，如 價值網路 和 價值商店。

這種型別的建模聽起來可能是學術性的，而且是隻有企業和企業架構師才關心的，但它是非常實際和廣泛適用的。

簡單地說，能力是企業認為自己具備的能力，即對內部和外部各方而言的能力。

讓這個概念有點難以理解的是，它們本質上描述了公司“做什麼”，而不是 “如何做”。

它是業務現實的抽象，將它們與經典的業務流程建模區分開來，後者通常側重於 "如何"完成工作。這種抽象性還使得能力本質上比其他方法更穩定，因為它們在實現時不會改變，比如使用軟體的自動化。他們改變的唯一原因是公司的戰略調整，比如決定轉向、擴充套件或搬出某個業務領域。

這種嚴格抽象的業務檢視為其支援元件（無論是角色（人員）、流程、資訊和資源）提供了一個顯式的業務上下文。

這個優勢的一個有趣的方面是能力需要相當獨立，這意味著它必須能夠以相對獨立的方式提供這種能力。

此外，這些能力自然是分層的和可分解的，這意味著一個頂級能力，例如銷售，將包含許多能力，這些能力又將包含另一組。級別的數量根據企業的規模和複雜性而有所不同，但通常有3-4個級別。 

儘管業務能力似乎只有業務和企業架構師關心，但它們的用途遠不止戰略規劃和文件，其中一些甚至可能與開發人員和軟體架構師相關。尤其是它們固有的獨立性和邏輯邊界，非常符合 SOA/微服務的自主性和顯式邊界原則，以及領域驅動設計中的有界上下文概念。

即使手頭沒有定義的業務能力模型，該概念也可用於將這些服務識別為啟發式。如果您可以將建議的邊界與可表徵為業務能力的事物相匹配，那麼您可能會獲得良好的自治服務。

業務能力如此通用的原因在於它們的描述性，它們很好地定義了問題空間，而對解決方案空間一無所知。它們是許多更詳細建模的良好基礎，從業務角度來看是穩定的，並且只有在業務本身發生變化時才會發生變化。

領域建模

通常，這種建模是協作完成的，讓所有具有正確業務知識的人都進入同一個房間。這不是少數人孤立地獨自做的事情，但有時從零開始，在邀請忙碌的人在會議上為其貢獻之前，先建立一個“稻草”模型，這可能是有利的。

在邀請人們參加研討會之前，務必明確提出期望。無論目標是定義整個企業的全域性圖，還是詳細說明較低階別的能力，都表明需要參與的人員。對於頂層對映，需要來自整個企業的高階業務主管、企業架構師和業務架構師，而對於特定能力的詳細描述，則需要對該部分有深入瞭解的人員，如產品經理、系統問題專家和軟體架構師。

儘管嘗試建立一個完整的能力圖似乎是明智的，從層次結構的頂層一直延伸到較低的層次，但這種努力很可能會掩蓋其好處。因此，根據手頭的具體目標調整計劃，無論是建立用於業務建模的頂層模型，還是模組化屬於這些頂層能力之一的軟體整體。

目標是捕獲和記錄代表企業現在做什麼以及它對未來的期望的能力。在大多數公司中，某種業務模型和業務架構已經存在並且應該作為輸入帶到研討會，無論是價值鏈分析、業務流程還是業務計劃。即使是現有的組織結構圖、核心業務實體的列表也可以獲得靈感。對於某些行業，甚至存在公開可用的參考模型，可以從中受益。

其他出色的建模和協作技術，如事件風暴、使用者故事對映、領域故事講述、業務模型畫布、示例對映、影響對映、沃德利對映等等，所有這些技術均由行業專家編寫擁有豐富的工具使用經驗。