私は、パイプラインと責任の連鎖の奇妙な融合のように見えるマルチプロセスアーキテクチャを構築しています。基本的に、私はキューによってリンクされたハンドラーのチェーンを持っています。各ハンドラーは、入力データを表すオブジェクトを受け取り、それを次のハンドラーに転送して作業を開始できるようにし、そのデータで何かできるかどうかを判断します。
あるステップが次のステップに実際には依存しないため、これをパイプラインと呼ぶことができるとは思いません。また、1つのハンドラーが他のハンドラーによるそのデータの処理を阻止できないため、これは従来の責任の連鎖ではないようです。このアーキテクチャを文書化するのに役立つこのデザインの名前はありますか？それとも、「責任のパイプライン」のようなものと呼ぶ必要がありますか？
連鎖を止めないという具体的なことでも、それは責任の連鎖だと思います。
いくつかのパターンは非常に似ており、バリエーションがあります。パターンがケースに適合するかどうかを確認する最善の方法は、その意図を調べることだと思います。GoFの本から：
責任の連鎖 「リクエストを処理する機会を複数のオブジェクトに与えることで、リクエストの送信者と受信者を結びつけることを避けてください。受信オブジェクトをチェーンし、オブジェクトが処理するまでチェーンに沿ってリクエストを渡します。」（223ページ）
したがって、ハンドラーとチェーンを通過するオブジェクトとの間に結合がない場合、たとえ処理されたとしても、オブジェクトが常にチェーンの最後に落ちることは問題ではないと思います。
あなたの説明から、これは別のものです。責任の連鎖とパイプラインの両方が、本質的にシリアル処理を扱います。少なくとも私があなたの説明を正しく理解していれば、あなたが持っているのは基本的に、データを並行して処理する多数の「プロセッサ要素」です。
通常、一連のオブザーバーを使用してそのような状況を処理しますが、あなたの説明はオブザーバーのパターンにも実際には適合しません。特に、各プロセッサ エレメントは、(少なくとも) 1 つの他のプロセッサ エレメントについて認識しているように見えます。オブザーバー パターンでは、通常、オブザーバーは互いに意識しません。それぞれがデータ ソースに自身を登録し、新しいデータや変更されたデータがあると、すべてのオブザーバーがデータ ソースから通知されます。
私の即時の反応は、あなたが行ったことの名前を探すよりも、オブザーバーパターンを使用した方がおそらく良いだろうということです. パターンのポイントの 1 つは、同様の問題を同様の方法で解決することです。物事の音から、これはおそらくもう少し用途が広く扱いやすいでしょう. たとえば、チェーンから 1 つのオブザーバーを削除する場合、別のオブザーバーを変更する必要があるようです。通常のオブザーバー パターンを使用すると、他のオブザーバーを変更せずに (そして、他のオブザーバーが何かが変更されたことにまったく気付かずに) オブザーバーを追加または削除できます。
編集: 独立した要素と連鎖した要素が混在している場合、2 つのバリエーションが考えられます。最初の (そしておそらく最もクリーンな) 方法は、最上位でオブザーバー パターンを使用することです。オブザーバーの一部は、それ自体がパイプラインになります。
もう 1 つの可能性は、VLIW プロセッサからトリックを盗み、特定の要素が前の要素の結果に依存するかどうかを示すフラグを最上位に持つことです。これにより、パイプラインと独立したオブザーバーを簡単に混在させることができます。また、(たとえば) 並列処理を行うことに関心がある場合は、独立したプロセスを並列で実行するのが非常に簡単になります。
これは、（データを含むイベントを介して）入力からの変更があることが各ハンドラーに通知されるため、オブザーバーパターンのように聞こえます。