複数のビジネスコンポーネント（顧客アプリケーション、ネットワーク、支払いなど）間の要求を仲介する大規模なミドルウェアインフラストラクチャがあるとします。ミドルウェアスタックは、オーケストレーション、ルーティング、変換、およびその他のものを担当します（GregorHohpeによるEnterpriseIntegration Patternsの本と同様）。
私の質問は、ミドルウェアにビジネスロジックを配置するのは良い設計ですか？
私のアプリAがミドルウェアからいくつかの顧客データを要求するとします。ただし、このデータを取得するには、顧客IDとその他のパラメーターを指定する必要があります。このパラメーターのフェッチは、要求元のアプリが行う必要がありますか、それともミドルウェアが顧客IDを受け取り、他のパラメーターを内部的にフェッチするインターフェースを「促進」して提供する責任がありますか？
これは（ビジネスロジックの定義のために）単純な質問ではないことは理解していますが、それが一般的なアプローチなのか、それともいくつかのガイドラインなのか疑問に思いました。
ルーティング、変換、オーケストレーションとは別に、機能要件を備えたミドルウェアをロードする際には、パフォーマンスに留意する必要があります。ミドルウェアは、エンドツーエンドのトランザクション寿命全体のほんの一部を占める必要があります。これは、ホストシステムの機能を補完しようとするのではなく、ミドルウェアのコア機能に集中することによってのみ達成できます。
これは「複合アプリケーション」パターンです。サービス指向アーキテクチャの心臓部。これがESBベンダーが販売しているものです。既存のアプリケーションから複合アプリケーションを作成する追加のビジネスロジックをどこかに配置する方法です。
複合アプリケーションは単なるルーティングではないため、これは単純ではありません。これは、ルーティングの上に階層化された適切な新しい複合トランザクションです。
ヒント。先に進む前に、優れたESBを取得することを検討してください。これはすぐに制御不能になり、追加のサポートがあると便利です。SunのJCAPSやOpenESBのようなものを購入しなくても、それが何をするのか、そしてそれらが複雑な複合アプリケーションをどのように編成するのかを学んだことは喜ばしいことです。
オーケストレーション、ルーティング、および変換。
技術的な理由で、ランダムに、または単に楽しみのために、これらのいずれも実行しません。ビジネス要件があるため、これらを実行します。つまり、ビジネスロジックが関係しています。
完全なビジネスシステムに欠けているのは、計算とレポートだけです（すでにセキュリティが確保されていると仮定しましょう！）。
非常に低レベルのネットワークを除いて、OSとストレージの問題は、コンピュータシステムを構成するほとんどすべてのものが存在します。これは、企業/政府/エンドユーザーがコンピュータシステムを存在させたいためです。
用語としての「ビジネスロジック」の選択は非常に貧弱であり、設計とアーキテクチャの無限の歪みをもたらしました。
最も優れた設計者/建築家がビジネスロジックで意味するのは、計算と分析です。
「％s/ビジネスロジック/計算/g」の場合、ほとんどのアーキテクチャの勅令はより理にかなっています。
ミドルウェアアプリケーションがそれを行う必要があります。システムAは、他のパラメーターが存在することを認識していないはずであり、それを取得する方法については確かに認識していません。