領域故事講述：協作構建領域驅動軟體 - Stefan Hofer

領域故事（Domain Storytelling）起源

我並沒有真正發明它，但我確實給它起了名字。實際上有幾個前輩。其中一個是我加入這家公司實習時第一次學到的技術，雖然他們使用了這個技術，而且他們有一個建模工具，但這是一種有不同模型型別的企業建模方法。也有這樣一種模型，它顯示了小棍子，與他們所謂的工作物件一起工作。

我們和我的同事，也就是我的合著者一起，所做的就是提煉出其中的精髓，使其易於使用，沒有前輩們所有的其他包袱，我們給你起了一個響亮的名字。

(Domain Storytelling)是一個關於領域的故事，關於在一個領域中發生的事情。但它也有點參考了領域驅動設計，因為我們認為，嗯，這確實是我們的關鍵實現。

多年來，我們一直在用這種更像大學的方法工作，並努力尋找行業中的人，在軟體開發社群，誰得到了它，誰理解它。

當我們發現DDD社群時，我們說，這就是我們的社群。他們就是這樣的人。他們重視協作式建模。他們重視視覺化建模工具。他們希望對一個領域有深入的瞭解。這就是DDD社群的完美工具。
 

誤解與常見的問題

軟體開發人員和業務部門的人之間的誤解，或者你可以稱之為業務領域，是一個常見的問題。

我認為這一直是個問題，至少在我的經驗中是這樣。在軟體開發中，人們想出了一些技術，試圖解決這個問題，例如，整個敏捷方法。

發明這個方法的原因之一，或者說人們想出了這個方法，或者說這個方法變得如此流行，是因為你想把了解這個領域的人聚集在一起，他們有這個需求，他們將使用這個軟體，還有開發這個軟體的人，並試圖在早期發現這些誤解，而不是像這樣：這個軟體建了兩年，他們在這個軟體上工作，最後他們發貨了，然後使用者說，"這不是我想要的東西"。

領域故事和其他視覺化建模技術，它們只是幫助緩解這個問題的額外手段，因為你很早就得到了一些東西，讓利益相關者、領域專家、未來的使用者有機會說，"哦，這不是我的意思。不，不，這不是我想讓你建立的東西"。

你可以將這種技術用於不同的目的，但其中一個目的是瞭解領域的情況。因此，如果你是一個領域的新手，如果你以前沒有在這個領域工作過，這是第一個可能出現誤解的點，因為你不理解這個領域的概念，人們使用的術語。

當我們對所謂的 "將要發生的過程 "進行建模時，我們也可以避免誤解。那麼，你想如何使用我們將要建立的那個軟體？你打算如何使用它？它將如何改變部門的工作流程？ 

 

瞭解領域的重要性

要建立一個可用的商業軟體，你必須首先了解這個領域。

其中一個很大的好處是，如果你問使用者他們想要什麼，他們往往不善於闡述一個軟體如何幫助他們解決問題，因為他們不是軟體開發的專家。他們不知道現代技術的所有手段，而且知道這些也不是他們的工作，因為他們是領域專家。他們不是軟體專家。

如果開發人員，如果開發團隊對該領域有了解，那是很好的，因為他們可以提出更好的解決方案，而不是僅僅依靠，嗯，這是使用者告訴我他們想要的東西，這就是我要建立的東西。但也許還有其他更好的解決方案。

我認為，作為一個軟體開發者，你的工作就是要有這些想法，思考我如何能從使用者的（角度）以最好的方式解決這個問題。而這不一定是未來使用者心中的同一個解決方案。他們往往受限於他們所知道的東西。他們被他們已經習慣使用的現有軟體系統所限制。

領域故事

• 這是兩件事的結合。
• 一種是象形語言，因此它是一種用於建模業務流程的符號。基本思想是我們有一組簡單的圖示。
  
  • 我們有“演員角色Actor”，他們是我們軟體系統中做事的人，故事圍繞著這些演員演進。所以他們是故事中的活躍部分。他們做什麼？嗯，他們創造東西，他們使用東西，他們交換東西，那些我們稱之為工作物件的東西，所以它們可以是物理的東西，比如紙上的檔案。
  • 然後我們有描繪活動的箭頭。這個想法是象形語言遵循自然語言。所以你可以大聲讀出來。故事由不止一個句子組成。
  • 我們如何表達一個序列？其他建模技術，它們從左到右或從上到下建模。但在這裡，我們使用數字。所以我們給箭頭編號，這讓我們有機會更自由地佈置故事。
  • 例如，將屬於同一子域或發生在同一位置的故事部分組合在一起。所以這給了我們更多的自由來佈置故事來表達一些額外的意義。
• 領域故事的第二部分是它也是一種研討會形式。我有時也會做的是您可以自己使用域講故事。但通常，這是一項協作活動。
  
  • 這意味著我們有有問題的人和有答案的人，我們將他們聚集在一起。例如，有問題的人是開發團隊的成員和有答案的人。他們是各種各樣的利益相關者。所以我們有系統的未來使用者。我們還有其他利益相關者。我們可能有產品經理或 PO、產品負責人和經理等等。我們將它們放在一個房間裡，或者可能在 Zoom 通話中。我們讓他們告訴我們有關他們領域的故事。
  • 什麼是故事？嗯，這是一個場景，它是一個領域中實際發生的事情的具體例子。因此，我們並不是在談論業務流程，因為這些都是可能發生的所有可能發生的事情，或者發生這種情況或發生那種情況。他們給我們舉了一個具體的例子。
  • 例如，典型案例或最常見的案例，或最簡單的案例，或常見的錯誤場景。我們採用這種情況並從頭到尾告訴它，沒有任何如果，沒有案例。我們只看最重要的例子。也許兩三個例子就足以真正理解一個業務流程。
  • 當領域專家講述故事時，有一個主持人。他或她，他們以視覺方式記錄領域故事，這意味著他們創造了象形語言的圖片，並且它同時發生。這為我們提供了一個很好的工具來處理這些誤解。因此，重要的是每個人都可以看到正在建立的圖片。
  • 這種研討會形式和在那裡建立的這種對話，至少與最終圖片和最終結果一樣重要。因為經常，根據我在研討會上的經驗，這就像一場篝火晚會。如果你看一下完成的圖片，那些在車間裡的人，他們就知道它是關於什麼的。如果您只是將它展示給其他人，那麼它與在建立它時在那裡是不同的。
• 這就是為什麼我通常會說，即使你可以獨立使用象形語言和研討會格式，但如果你結合使用它，你會從中獲得最大的好處。

DDD角度

• 您不必使用領域驅動設計來應用此技術。在我們進入這個領域驅動設計社群之前，我們已經應用了幾年，它仍然有效。
• 從某種意義上說，它是領域驅動的，它是關於業務、關於領域、關於人、關於人們的任務和活動的。但它不受域驅動設計的這種特殊方法的約束。
• 但是，如果您從事領域驅動設計，您將希望看到它可以幫助您解決該領域的某些活動或某些問題。例如，為有界上下文尋找邊界，或開發可實現的域模型。
• 我認為 Domain Storytelling 確實豐富了 DDD 工具箱。但是沒有必要為此使用 DDD。
• 事實上，即使沒有開發軟體的目標，您也可以使用 Domain Storytelling。因此，人們使用它來最佳化組織中的工作流程，或做出“制定或購買”決策。

當領域專家不可用時

• 如果您檢視分析領域的經典目的，那麼我認為沒有領域專家就行不通。但是，例如，如果您處於初創公司的情況，或者如果我擁有非常技術性的領域，那麼您可以與技術專家一起完成。
• 我們在那裡所做的是，我正在與對這個新業務領域有這個想法的經理一起工作，他們腦子裡有這個商業模式。他們正試圖講述他們擁有的這個新商業理念的故事。所以還沒有使用者。目前還沒有其他領域專家。這只是他們腦海中的一個想法。
• 你能用它來編故事嗎？這非常關鍵。否則，它只是一種商業模式。但是把它帶入生活，讓它活起來，這是你可以用故事做得很好的事情。

領域故事工具

• 這種象形文字與人們通常知道的其他符號大不相同。它看起來與 UML 活動圖或 BPMN 大不相同。所以我建議先練習一下這種象形語言。
• 首先，要充分理解這是如何寫下來的，因為這會影響建模會話的速度。一方面，您不希望與很多人進行建模會議，而您是阻礙所有人的人。所以你應該非常流利地使用這種象形語言。
• 當然，更復雜的部分是與人合作。這並不是這種技術獨有的問題。當你與一群有不同觀點、不同觀點的人一起工作時，這是一個普遍的問題。
• 你怎麼能為此做好準備？而我通常推薦和我做的是，首先做一個一對一的採訪風格的講故事工作坊。例如，找一個同事，讓他們告訴你一個故事，然後你試著想象一下。因為那時你只需要和一個人打交道，通常他們不會不同意自己，所以會容易一些。然後，以此為基礎，與更多人一起做。

象形語言

• 領域故事可以在不同的粒度級別上播放。所以我們可以對某事有一個粗粒度的概述，或者有一個細粒度的故事。不同層次的細節——這就是我們所說的故事的“範圍”。故事的範圍由幾個方面組成。所以你有它的粒度。
• 然後我已經談到的另一個因素是您檢視的時間點。您是否以目前的方式看待事物？我們稱之為“原樣”的流程。所以這更多是使用領域故事的分析方式，分析它們。或者你想設計一些新的東西？一個新流程以及軟體如何支援它？然後這是一個在未來上演的“未來”故事。
• 根據他們的目標，您可以選擇不同的範圍。這也決定了您必須在故事中加入多少細節。
• 如果你稍微細化一點，你會看到軟體系統，它們也被建模為演員。因為它們通常在流程中也很活躍。因此，他們為您提供了一些資訊。他們計算一些東西。他們生成報告或他們所做的任何事情。因此，對於域故事來說，其中包含少數演員是很典型的。因此，您將擁有使用系統（和系統）本身的人。甚至可能是一些沒有直接使用者的後臺系統。
• 但是當它變得過於技術性時，例如你說的 API，或者在我提到技術協議之前，我通常會切換到其他形式的建模方法。這也是典型的，在一個專案中，我經常結合不同的建模方法，以便我為手頭的每一項任務擁有完美的工具。在某種程度上，您仍然可以使用 Domain Storytelling 來做到這一點，但通常，我會將它們推薦給其他一些更適合實際建模軟體工作方式的建模方法。

翻譯成軟體

• 最常見的是，我們首先翻譯它，或者我們用它來推導，提出需求。例如，使用者故事。它不一定是使用者故事。你也可以有一些其他的格式，例如用例。
• 當然，這與領域故事的視覺化方式有關，因為那裡還有演員。那些是使用者。好吧，他們是做什麼的？這就是活動箭頭的描述。所以很容易翻譯。
• 對於涉及業務流程的各種本質上是過程的需求，您可以透過對領域故事建模然後將它們轉換為使用者故事來非常容易地提出它們。然後，當然，您需要在需求中新增一些細節。
• 從領域故事中，我們得出粗粒度的需求，然後您將繼續在其中投入更多的工作，並提出驗收標準之類的東西。從那裡開始，您將進入軟體開發領域。

與事件風暴的區別

• 我通常說 Event Storming、Domain Storytelling，還有其他技術，如使用者故事對映或示例對映，它們都像家庭成員。所以他們都是這個協同建模方法家族的成員，這意味著他們有一些共同點。但是，他們也有一些領域，其中一個比另一個更適合。
• 當然，建模語言有點不同，因為它們有這些便箋並且它們是彩色編碼的。簡報中最重要的元素是領域中發生的事件或事情。您將業務流程表達為從左到右的一系列事件，這就是您的時間線。這已經是很大的不同了。
• 如果它是一個涉及很多人的問題、領域或業務流程，並且會進行很多互動。在涉及多個系統之後，瞭解有關此互動的更多資訊是很有意義的。我們想看看誰和誰一起做什麼。然後我會選擇Domain Storytelling。
• 如果我知道該領域更多地是關於狀態變化，更多地是關於這個時間序列，那麼事件風暴可能是更好的選擇。
• 有時也可以很有趣地詢問這個過程已經成熟到什麼程度。那麼它是人們真正可以談論的東西嗎？然後，再次，我寧願使用域講故事。
• 如果他們需要 Event Storming 的這種頭腦風暴方面的內容，可以有一個促進者，但它不像 Domain Storytelling 那樣嚴格，所以每個人都只是從在牆上貼上橙色便籤開始。因此，如果我的印象是這有助於讓他們自由表達他們的想法，那麼我寧願選擇 Event Storming。
• 這裡有不同的因素在起作用。我經常在同一個專案或同一個車間中使用這兩種技術。

線上協作研討會

• 令我驚訝的是，這非常有效。我從事線上協作建模已經將近兩年了。我無法想象它會運作得這麼好。但是，您仍然需要注意一些事情。這個由協作建模從業者組成的整個社群，他們在部落格文章和聚會中分享了他們的經驗。
• 最重要的方面是您有線上建模工具或一些您可以共享並且每個人都可以看到的建模工具。因此，無論是您使用的虛擬白板還是其他建模工具，版主都會分享，每個人都可以看到和互動。
• 特別是對於較大的團體，擁有第二個促進者或主持人真的很有好處。因為在 Zoom 通話中、在虛擬會議中關注人員比在現實生活中的會議中更具挑戰性。如果你們都在一個房間裡，肢體語言很容易丟失，有時人們會關掉攝像頭，那麼你就失去了獲取反饋的途徑。
• 一個小技巧是，例如，另一個人跟蹤人們的活躍程度。所以只是一個人還沒有說什麼，那麼我們可以主動徵求這個人的意見，比如。
• 我認為協作建模最重要的工具是每個人都可以看到模型。因此，您將不得不使用一些軟體工具進行建模。經典的白板或牆上的造型對於這個來說是不可能的。
• 當談到域故事講述時，我們為此構建了自己的小型開源工具。我們構建的工具稱為 Egon.io。它是開源的。我認為主要優點之一是它可以重播故事。所以這實際上是我建造它的原因之一。
• 如果你只使用一些通用的繪圖工具，繪圖與建模是不一樣的。所以繪圖工具不知道符號和語法。