事件風暴與領域故事的比較
DDD關鍵是發現有界上下文(bounded context),事件風暴(Event Storming)和領域故事(Domain Story)是兩種不同的查詢上下文邊界方法,他們之間有什麼異同?
Eric Evans在他的“領域驅動設計”一書中稱他們與領域專家進行了對話,這應該引導軟體開發人員更深入地瞭解這個領域。Evans建議開發一個共享域模型,作為領域專家和IT之間的橋樑,它以無處不在的語言編寫並由應用程式程式碼實現。
近年來,為這些活動建立了兩種現代研討會形式:
1. 阿爾貝託·布蘭多利尼(Alberto Brandolini)在2013年展示了他的“Event Storming”,同時風靡全球(雙關語);
2. 2016年,Workplace Solutions公司的員工向公眾展示了以“Domain Storytelling”為名的利益相關者訪談的內部格式。
這兩種格式都有助於為IT專業人員提供對域的深入洞察並開發域的通用視覺化模型。然而,這兩種格式我想在本文中描述條目的優點和缺點。
什麼是領域故事?
早在IT系統或書面記錄存在之前,故事就是知識轉移和人性傳播的一種形式。我們進行了生物學上的改進,以便很好地內化故事。領域故事利用這一事實在域專家或IT系統使用者及其開發人員之間建立一種移情的知識轉移形式。
在領域故事Workshop中,要求領域專家使用故事作為示例來解釋他完成特定工作流程所採取的步驟。各個工作步驟的記錄以簡單的象形圖形式記錄。
這些象形圖使用符號語言來解釋工作流程。此符號語言呼叫所謂的參與者(例如使用者或系統),他們在 所謂的工作物件(例如文件,表單或資料記錄)的幫助下執行活動。通過按箭頭方向按照所述順序閱讀圖表,他們講述了領域專家的故事。象形圖中的名稱來自領域語言,因此形成了普遍存在的語言的指示。
然而,與其他流程建模符號相反,僅與系統一起制定單個示例性互動,而不是與所有可能的錯誤情況的所有可能互動。
什麼是事件風暴?
“事件風暴”不是像領域股市那樣定義明確的格式,而是一組具有相似性的相關格式。阿爾貝託通常稱事件建模為:長長的牆壁(“無限建模空間”),上面貼滿即時貼(“無限即時貼”),最後是人的問題以及人們的答案。
最著名的兩個焦點是“大圖”和“設計級別”:
1. “大圖”著眼於從高處開始到結束的完整過程,並識別痛點或上下文短語。
2. 另一方面,在“設計級別”格式中,諸如聚合邊界的實現細節是從領域事件匯出的。
此外,還有其他格式,專注於使用者體驗,價值流等。但是,根據我的經驗,大圖片更頻繁地用於領域專家的知識處理。
在格式的開頭,每個參與者首先在大規模平行和混亂階段以“在牆上”的粘滯便箋的形式投射他的主觀領域。只有逐步發展的結構和參與者的個人心理模型合併為一個“大局”。
由此產生的結構是即時的,並不必與參與者在研討會之前想到的模型相對應。領域也在這個緊急階段用於沿時間線組織事件。領域專家沿著時間軸走過模型並試圖通過一個未記錄的例子來解釋它。關於這些領域的知識仍然被研討會參與者拒絕。
然而,在大型公司中,這個過程也首次出現在筒倉邊界上(我引用了我的一個客戶:“最後我明白你在那裡做了什麼!”)。關於準確性,必要性和其他流程細節,有很多有趣的討論。Alberto將特別有爭議的網站稱為“熱點”,在研討會期間無法澄清或解決。在研討會結束時,這些熱點將通過“箭頭”或“點投票”進行優先排序,並採取進一步行動。
這可能是特別緻命的功能障礙,並且整個系統的瓶頸被曝光。然後可以公開解決這些深刻的系統性問題,並嘗試解決方案。在這種形式中使用,事件風暴不僅僅是知識運算的一種形式。它是功能失調的複雜系統的一種治療形式。
該怎麼用?
這兩種格式都具有領域焦點和引人注目的圖形符號,非常適合與領域專家一起開發無處不在的語言和領域模型。但問題仍然存在,這些格式各自的優勢是什麼?
事件風暴似乎是一個創新,破壞性和高度不正常的域方法,非常有效地開發新的,突發的結構和觀念(Cynefin模型的行家認為:我們在事件從創意的“混沌”域緩緩移動攻堅到“複雜”,我們看到新的解決方案出現)或為所有相關人員制定組織功能障礙。
進一步強攻事件凸顯它的許多新增在這篇文章中,變體可用於其它用途,如建模單元,分析UX等的時間記錄相當糟糕,被使用。所有這些使得格式非常通用。
相比之下,領域故事明顯地以象形圖的形式出現在易於理解的工件之前,其中需要書面的過程文件。也許這就是為什麼,根據我的經驗,接受領域故事更高的原因之一,特別是對於那些在文件繁重的流程中具有強大背景的參與者,而不是在事件風暴中。
這樣一個領域故事的工作坊也可以很好地記錄下來,從而為後人提供領域知識文件的另一種形式。事件風暴對於錄製來說太混亂了,對於沒有參與其創作的人來說,結果模型往往是壓倒性的。
另一點是在高度分散的團隊中適合領域故事,事件風暴不能使用,而領域故事可以通過視訊會議系統非常有效實施。
兩種格式的共同之處在於它們可以幫助在系統中查詢上下文邊界。我認為事件風暴在這裡更快地導致結果,領域故事會對所有圖示進行評估。
相關文章
- 事件風暴 - 分解問題領域的最佳實踐事件
- 使用者故事/事件風暴中的功能與能力如何區分? - Killick事件
- 事件風暴 vs 事件建模事件
- 人壽保險銷售平臺的領域驅動設計和事件風暴案例分享 -James Hickey事件
- DDD中事件與命令比較事件
- 大局事件風暴:尋找差距事件
- DDD事件風暴的詳細議程事件
- 事件風暴EventStorming與事件建模EventModeling的區別 | rafalmaciag事件ORMMac
- 暴風魔鏡市場幾何? 手機盒子在VR領域成功嗎?VR
- DDD領域驅動設計:領域事件事件
- 資料分析領域幾個常用工具比較
- DDD事件風暴研討會備忘單事件
- WebSockets與伺服器傳送事件SSE比較Web伺服器事件
- 比較全的oracle事件解釋Oracle事件
- 領域驅動設計戰術模式--領域事件模式事件
- 戲說領域驅動設計(廿五)——領域事件事件
- 通過事件風暴發現業務流程 - Sarah Denayer事件
- 領域服務和領域事件如何取捨?或共存?事件
- 透過事件風暴和DDD建立微服務時優先考慮事件事件微服務
- 領域故事講述:協作構建領域驅動軟體 - Stefan Hofer
- [翻譯]-領域事件-Martin Fowler事件
- AI領域的灌水之風如何破局?AI
- GitHub - mariuszgil/awesome-eventstorming: 事件風暴建模工具集GithubORM事件
- 領域驅動模型DDD(二)——領域事件的訂閱/釋出實踐模型事件
- DDD-領域物件與領域服務物件
- 事件處理器中對領域的操作事件
- 事件風暴研討會準備和三種型別事件型別
- 領域事件和整合事件沒那麼高大上事件
- Abp領域事件(EventBus)原始碼解析事件原始碼
- Java反應式事件溯源:領域Java事件
- 在微服務中使用領域事件微服務事件
- 架構強弱比較:基於業務領域劃分的團隊更強 - martinfowler架構
- PostgreSQL與MySQL的比較 - hackrMySql
- MVVM與MVC模式的比較MVVMMVC模式
- XTask與RxJava的使用比較RxJava
- JavaScript 與 Java、PHP 的比較JavaScriptPHP
- Hadoop與Spark的比較HadoopSpark
- CMM/CMMI 與敏捷的比較敏捷