根據業務能力實現DDD建模 - trond

banq發表於2020-06-22

將大型複雜系統模組化為更小和更易於管理的部分是一種最佳實踐,這不僅是為了降低每個部分的認知負擔,而且還可以降低團隊的獨立性和運營彈性。棘手的一點是如何劃定邊界,使整個系統穩定而可持續。
帶有邊界的上下文是領域驅動設計的一種方法,業務領域的語言用作指導,還有另一種方法是從業務模型定義的功能中汲取靈感,以找到領域中的自然邊界。

“業務能力是企業為實現特定目的或成果而擁有或交換的特定能力。” –烏爾裡希·霍曼(Ulrich Homann)

這是Leanpub上免費的Visual Collaboration Tools書籍中釋出的有關業務能力建模的章節的精簡版。

什麼是業務能力
業務能力模型經常用於企業體系結構中,以一種整體描述公司的方式,代表組織的業務模型,但與結構,流程,人員或資源(例如IT系統,建築物,材料,硬體,工具,知識等)無關,它嚴格描述了公司的職能。
業務能力建模與   公司基於資源的檢視有關,通常被視為對它的擴充套件,因為它還支援 經典價值鏈之外的其他  價值配置,例如  價值網路  和  價值商店
這種型別的建模聽起來聽起來像是學術性的,只有企業和企業架構師才關心,但它是切實的並且廣泛適用。
簡而言之,這些功能是企業內部和外部各方都認為自己具有的職能。
它是業務現實的一種抽象,使它們與經典業務流程建模(通常專注於如何  完成事情)區分開  。這種抽象性也使這些功能固有地比其他方法更穩定,因為它們的實現在執行時不會改變,例如人工執行和使用軟體自動化時都不會改變。他們發生改變的唯一原因是公司的戰略調整,例如決策進入、擴充套件或移出某些業務領域。
這種嚴格而抽象的業務檢視賦予其使能元件,包括角色(人員),流程,資訊和資源,以及明確的業務上下文。
有趣的是,功能必須相當獨立,這意味著它必須能夠以相對無關的方式實現自己的功能。此外,這些功能自然是分層的和可分解的,這意味著一個頂級功能(例如Sales)將包含許多功能,而這些功能又將包含另一組功能。級別的數量根據企業的規模和複雜性而有所不同,但是通常有3-4個級別。 
儘管似乎業務功能只是業務和企業架構師所關心的,但它們可以用於的範圍遠遠超過戰略規劃和文件編制,其中某些功能甚至與開發人員和軟體架構師有關。特別是它們的固有獨立性和邏輯邊界非常適合SOA /微服務的自治性和顯式邊界原則,以及域驅動設計中的有界上下文概念。
即使手頭沒有定義的業務能力模型,該概念也可以用於將一些服務作為啟發入口。如果您可以將建議的邊界與可以描述為業務能力的特徵相匹配,則可能會獲得良好的自治服務。
使業務功能如此通用的原因在於其描述性,它們很好地定義了問題空間,而對解決方案空間無關。它們是進行更多詳細建模的良好基礎,從業務角度來看是穩定的,並且僅在業務本身發生變化時才發生變化。

如何建立模型
通常,這種建模是協作完成的,將具有適當業務知識的所有人員都放在同一個房間中。這不是少數人孤立地做的事情,但有時在從頭開始時有人邀請一個忙碌的人在車間裡為它做模型之前,先建立一個稻草模型是有好處的。
在邀請人們參加研討會之前,明確期望是非常重要的。目標是定義整個企業的全景圖還是要詳細說明較低階別的功能,都表明需要誰參與。對於頂層對映,需要企業中的高階業務主管,企業架構師和業務架構師,而對於特定功能的詳細說明,則需要對這一部分有深入瞭解的人員,例如產品經理,系統問題專家和軟體建築師。儘管嘗試建立一個完整的功能圖似乎很明智,從頭到尾一直到層次結構的下層,但這種努力很可能使收益蒙上陰影。因此,應根據當前的具體目標調整主動權,
目的是捕獲和記錄代表企業現在所做的事情以及對未來的期望的能力。在大多數公司中,已經存在某種業務模型和業務架構,應該將其作為輸入,包括價值鏈分析,業務流程和業務計劃。即使是現有的組織結構圖,對於靈感以及核心業務實體列表也可能很有趣。對於某些行業,甚至存在可以參考的公開可用參考模型。
要了解有關業務能力建模的更多資訊,以及如何在實踐中進行操作,以及如何舉辦研討會以及如何定義和記錄結果的技巧,請查閱Leanpub上免費的Visual Collaboration Tools書籍。在這裡,您還可以瞭解有關許多其他出色的建模和協作技術的資訊,例如事件風暴,使用者故事對映,域故事講述,業務模型畫布,示例對映,影響對映,Wardley對映等等,所有這些都是由行業專家撰寫的有很多使用工具的經驗。透過支付少量費用,您還可以為良好的事業做出貢獻,這是一項技術多元化計劃。
 

相關文章