現代軟體開發不僅需要對技術有紮實的理解，還需要對驅動軟體的業務有全面的掌握。這包括操作領域和組織結構的知識。幸運的是，軟體開發行業已經開發了各種技術來幫助完成這項任務。
包含眾所周知的模式和工具的常見保護傘是領域驅動設計（DDD）。
背景
在 SoftwareMill，我們專注於協助各種規模的企業完成數字化轉型之旅。我們的產品組合包含廣泛的專案，每個專案都涉及多個行業的複雜業務領域。我們的專業知識包括端到端專案，涉及分析和收集需求、制定和實施解決方案，以及持續的維護和支援。
然而，這些專案大多數都受到保密協議 (NDA) 的保護，這限制了我們公開分享細節的能力。儘管如此，由於我們致力於傳播知識和經驗，我們正在探索如何在軟體開發過程中展示我們與客戶合作的方式。這就是這個專案的想法的誕生。
我們的目標是傳播領域驅動設計的知識和經驗，以及我們在客戶專案中經常使用的多種補充工具和技術。透過展示它，我們的目標是與社群分享我們的經驗和知識，同時展示我們在領域驅動設計的某些方面的獨特方法，這些方法源自 SoftwareMill 在遠端工作中的經驗。
採取的行動
意識到這是一件大事，我們決定將我們的專案分為幾個部分。在此階段，我們的目標是從現實生活領域選擇一個示例，並將其分解為基本元素，以理解這個特定業務方面的運作方式。
那麼，我們計劃如何實現這一目標呢？透過採用與現實生活中的客戶相同的方法。
當客戶尋求我們的幫助時，我們首先需要幫助來充分掌握需求。我們也可能不清楚他們的業務如何運作、如何產生收入以及使該業務成功的其他關鍵方面。要開發可靠、精心設計的解決方案，對這些要素進行深入徹底的瞭解至關重要。
因此，我們通常從一系列研討會開始，旨在瞭解客戶的業務、需求和要求。有趣的是，這些會議有時甚至可以幫助客戶更好地瞭解自己的業務或在研討會流程中找到潛在的改進之處。
我們在此階段採用各種技術，但最有效的技術之一是（大局）事件風暴研討會。這種方法對於探索其中涉及的業務領域、流程和參與者特別有用。
事件風暴研討會是我們希望在該專案的第一階段向您展示的技術，它有兩個目標。
- 首先是定義標準並選擇我們將在整個專案中處理的領域。
- 第二個目標是組織和開展大局事件風暴會議，這將有助於我們更深入地瞭解所選領域。
什麼是領域驅動設計？
雖然本文的主要目標不是徹底解釋 DDD，但對該術語代表的含義有一個基本的瞭解對於更好地掌握該專案至關重要。因此，我將簡短地解釋這種方法。
在DDD中，程式碼的結構、邏輯和語言與業務領域相匹配，通常用所謂的通用語言來表達，使軟體更加相關、直觀、更能適應業務變化。這種方法對於業務概念和規則發揮關鍵作用的複雜領域特別有價值。
領域驅動設計非常重視領域模型的開發，該模型作為概念框架來捕獲業務領域的細微差別、操作和規則。該模型透過開發人員和領域專家之間的協作不斷完善，確保它仍然忠實地代表了領域的複雜性。
領域模型成為系統的基礎，指導功能的設計和實現，並確保軟體能夠隨著業務環境的變化而不斷髮展。
選擇複雜的業務領域
我們花了一些時間來尋找合適的域。一方面，我們希望避免出現過於瑣碎的問題，因為這會將我們的任務簡化為基本的 CRUD（建立、讀取、更新、刪除）操作。另一方面，選擇過於複雜的領域可能會削弱我們有效展示它的能力，因為需要付出很大的努力來解釋其複雜性。
另一個考慮因素是我們對領域知識的獲取；我們不能選擇一個我們完全陌生的領域，或者我們缺乏專業知識的聯絡，因為執行這樣的專案即使不是不可能，也是極具挑戰性的。此外，我們必須留意所有已落實的保密協議。
最後，我們決定重點關注我們公司內部完善且我們擁有豐富領域專業知識的流程：裝置/裝置管理流程。每當我們的同事需要新裝置時，無論是需要計算機的新加入者，還是由於裝置損壞或根本效能不足以滿足我們的日常軟體開發需求，此過程都會發揮作用。
我們的管理團隊在處理這一過程中發揮著關鍵作用。他們管理可用裝置的庫存，包括備用裝置和緊急裝置，還確定何時訂購新裝置或退役現有裝置。
乍一看，這似乎並不太複雜。然而，我們在這個過程中發現了一些細微差別，我們的目的是在本部落格文章系列中強調這些細微差別。我們對這個選擇感到滿意，因為該過程足夠簡單，可以演示，但超出了基本的 CRUD 操作。此外，每個人都或多或少地瞭解這個過程是如何運作的，至少在高水平上，這使得掌握我們開發的無處不在的語言變得相當容易。
團隊
在選擇了我們想要解決的業務流程之後，是時候深入研究這個領域了。作為開發人員，我們對庫存流程的理解僅限於使用者的角度（是的，我們需要計算機和其他裝置）並且非常膚淺。因此，我們需要專家的幫助來進行大局事件風暴會議，以更深入地瞭解該領域。
選擇合適的事件風暴參與者對於本次研討會的成功至關重要。在沒有適當專家的情況下進行可能會導致時間浪費。這些“合適的人”是誰？他們通常是能夠回答開發人員或建模人員問題的人。這些人可能是作為執行者、使用者、主管或設計者參與流程的人。
包括對正在探索的領域具有不同觀點的人也是有益的。更多的多樣性意味著更好的結果，但參與者太多也會導致混亂。
在我們的例子中，選擇合適的參與者相對簡單。我們邀請了來自管理部門的親愛的同事，他們既是 SoftwareMill 裝置管理流程的使用者又是設計者。請認識一下馬爾戈西亞和喬安娜。
所以，我們找到了有答案的人。
接下來，我們需要能夠提出正確問題的人。
我的同事 Michał 和我自己恰如其分地擔任了這個角色
每個事件風暴會議都需要一個人來確保會議目標的實現。此人負責維持參與者的參與度和精力。我們的會議由 Mateusz 熟練地主持，他擅長管理混亂並非常有效地引導團隊動態。
事件風暴研討會策劃
在啟動會議之前，我們採取了一些措施來提高會議的成功機會。首先，我們向管理專家介紹了事件風暴研討會形式。我們解釋了他們在會議期間可以期待什麼、如何進行以及如何為此做好準備（設定 Miro 帳戶、確保良好的耳機設定等）。這並不是事件風暴的詳盡概述，而是一些關鍵的預告片。通常，主持人會在研討會期間詳細闡述細節。
值得一提的是，會議是使用Miro線上進行的。大多數關於事件風暴的資源，包括其建立者阿爾貝託·布蘭多里尼（Alberto Brandolini），都建議在一個房間裡進行會議，房間裡有真正的便利貼和一張巨大的空白紙，以便在牆上提供無限的建模空間（這種方法在大流行期間發生了變化）。雖然我同意在同一房間見證彼此的情緒對於此類研討會是有利的，但在 SoftwareMill，我們在遠端工作方面擁有豐富的經驗。
作為一家自成立以來完全遠端的公司，線上會議自然是我們的首選。我們在遠端工具方面的豐富經驗極大地幫助我們減輕了遠端研討會的挑戰。這種方法是我們通常與客戶合作的方式，我們希望展示這一方面。
然後，我們安排了第一場會議。我們知道會議時間不宜太長，以保持每個人的注意力。因此，我們分配了 5 小時的時間段，預計在特定研討會部分之後休息並繼續進行另一場會議。這是遠端事件風暴的好處：將研討會分成幾個較短的會議要容易得多，因為不需要將所有參與者聚集在一個位置。這種方法有助於讓參與者保持專注並保持良好的心情。
最後，Mateusz 設定了 Miro 板。他邀請所有參與者參加 Google Meet 會議，我們都熱切地等待著第一次事件風暴會議。