要求串流圖

在 Thoughtworks 與同事相處，你很快就會得到一個印象，那就是唯一好的企業服務匯流排 (ESB) 是死掉的 ESB。Jim Webber 稱它們為錯誤的義大利麵盒。因此，聽到有人試圖將它們從不需要它們的系統中移除的故事並不少見。

在一位客戶那裡展開了一場激戰，這讓我想起我年輕時玩龍與地下城。Webber 揮劍卻落空，因為 ESB 的 AC 是 2，Evan 命中並擲出 2d8，造成 6 點傷害。Erik 最後施放「召喚要求串流圖」咒語，終於殺死了它。

那麼 Erik Dörnenburg 的決定性咒語是什麼？基本上，這個想法是採用一個簡單的要求，並展示要求和回應的資料如何通過應用程式的各個層級。Erik 列印出所有你需要閱讀的程式碼，以了解這將如何運作，這些程式碼長達數頁。他也製作了這張圖表。

在敏捷圈中，目前流行的做法是進行價值串流對應，以找出軟體開發流程中的浪費。我將其視為要求串流圖，因為它也採用一個要求，並展示它如何通過各個層級，讓我們能夠視覺化正在發生的事情，並思考各個層級的成本和價值。

分層是建置軟體應用程式的基本工具。但就像生活中大多數基本的事物一樣，過猶不及。像這樣的視覺化（或多頁程式碼）可以幫助你找到「剛好夠用」的地方。

然而，有一個危險。如果你確實需要將資料從一種形式轉換為另一種形式，通常執行一些小的轉換會比一次大的轉換更好。你應該避免不必要的轉換，而不是壓縮需要的轉換。