リクエストストリームマップ

Thoughtworksの同僚と一緒にいるとすぐに、唯一まともなエンタープライズサービスバス(ESB)は死んだESBだけだという印象を受ける。Jim Webberはそれらを「エラーだらけのパスタの箱」と呼ぶ。システムに必要のないESBをシステムから排除しようとする話は珍しくない。

あるクライアントとの激しい戦いは、若い頃に遊んでいたD&Dを思い出させた。Webberは攻撃を外した。ESBのAC（アーマー・クラス）は2だった。Evanが攻撃を当て、2d8振ってダメージ6を与えた。Erikは最終的に「リクエストストリームマップの召喚」を唱えてESBにとどめを刺した。

ではErik Dörnenburgの決定的呪文は何だったのだろうか？実際には、単純なリクエストを取り、リクエストとレスポンスのデータがアプリケーションレイヤーをどのように通過するかを示すというアイデアだった。Erikはこの仕組みを理解するために必要なコードをすべて印刷したが、それは数ページにも及んだ。また、次の図も作成した。

アジャイル界隈では現在、ソフトウェア開発プロセスでの無駄を発見する方法としてバリューストリームマッピングを行うのが流行っている。リクエストストリームマップは同様のリクエストを取り、リクエストがレイヤー間をどのように移動するかを示して、何が起こっているのかを視覚化し、レイヤーのコストと価値について考えることができるため、私はこの方法をリクエストストリームマップと呼んでいる。

ソフトウェアアプリケーションの構築には階層化が不可欠なツールである。しかし、人生におけるほとんどの必須アイテムと同様に、過剰は欠如と同じくらい問題になる可能性がある。このような視覚化(または複数のコードページ)は、「十分な」ものがどこにあるかを見つけるのに役立つ。

ただし、1つのデータ形式を別のデータ形式に変換する必要がある場合は、大きな変換を行うよりも小さな変換を複数回行った方が通常はよい。不要な変換は避け、必要な変換を圧縮する必要がある。