请求流图

在 Thoughtworks 与我的同事们待在一起，你很快就会发现，唯一好的企业服务总线 (ESB) 就是一个已死的 ESB。Jim Webber 将它们称为错误的意大利面盒。因此，听到人们试图从不需要它们的系统中移除它们的故事并不罕见。

在一客户处发生了战斗，这让我回想起我年轻时玩 D&D 的日子。Webber 挥舞但未命中，因为 ESB 的 AC 为 2，Evan 命中并掷出 2d8 获得 6 点伤害。Erik 最终通过施放 "召唤请求流图" 来杀死它。

那么 Erik Dörnenburg 的决定性法术是什么呢？本质上，这个想法是获取一个简单的请求，并展示请求和响应的数据是如何通过应用程序的各个层传递的。Erik 打印出了理解其工作原理所需的所有代码，这些代码占了好几页。他还制作了这张图。

在敏捷圈子里，目前流行的做法是进行价值流图，以发现软件开发过程中的浪费。我认为这是一种请求流图，因为它同样会获取一个请求，并展示它如何通过各个层移动，从而让我们可视化正在发生的事情，并思考各个层的成本和价值。

分层是构建软件应用程序的重要工具。但就像生活中大多数重要的事情一样，过量几乎和过少一样成问题。像这样的可视化（或多页代码）可以帮助你找到“适量”的点。

然而，有一个危险。如果你确实需要将数据从一种形式转换为另一种形式，通常最好进行几次小的转换，而不是一次大的转换。你想要避免不必要的转换，而不是压缩你需要的转换。