イベントコラボレーション

リスク追跡コンポーネントの追加

これまでは、トレーダーと証券取引所がこれら2つのスタイルでどのように連携するかを見てきました。3番目のコンポーネントを追加する方法が2つのスタイルでどのように異なるかを確認することで、違いをさらに理解できます。

追加する3番目のコンポーネントは、リスク管理コンポーネントです。その仕事は、特定の株式を持つすべてのトレーダーの未処理の総量を確認することです。

クラス StockRrRiskTester...

  [Test]
  public void ShouldTrackTotalOutstandingVolumeForOrders() {
      RiskTracker tracker = new RiskTracker(null);
      traderA.PlaceOrder("TW", 1000);
      traderA.PlaceOrder("ICMF", 7000);
      Trader traderB = new Trader();
      traderB.PlaceOrder("TW", 500);
      Assert.AreEqual(1500, tracker.TotalExposure("TW"));
  }

さらに、リスク管理システムは、未処理の合計がプリセット制限を超えた場合にアラートメッセージを送信し、制限を下回った場合はアラートをキャンセルする必要があります。

クラス StockRrRiskTester...

  [Test]
  public void ShouldTrackAlertWhenOverLimitForStock() {
      string symbol = "TW";
      ServiceLocator.RiskTracker.SetLimit(symbol, 2000);
      traderA.PlaceOrder(symbol, 2001);
      Assert.AreEqual(1, ServiceLocator.AlertGateway.AlertsSent);
  } 

これが機能するには、リスク管理システムが注文の配置（エクスポージャーの増加）と注文の実行（エクスポージャーの減少）の両方に関与する必要があります。

リクエスト/レスポンスシナリオから見てみましょう。配置から始めます。注文が送信されるたびにリスクマネージャーに警告するように、証券取引所オブジェクトの送信メソッドを変更することを選択しました。

クラス StockExchange...

  public void SubmitOrder(Order order) {
      outstandingOrders.Add(order);
      ServiceLocator.RiskTracker.CheckForAlertsOnOrderPlacement(order.Stock);
  } 

この変更はトレーダーで行うこともできますが、取引所を選択しました。これは、実行のためにとにかくこの依存関係が必要になるため、トレーダーからリスクトラッカーへの依存関係を作成することを回避できるためです。

リスクトラッカーが総エクスポージャーを判断するには、関連する証券取引所に対してクエリを発行します。

クラス RiskTracker...

  public int TotalExposure(string symbol) {
      return ServiceLocator.StockExchangeFor(symbol).OutstandingVolumeForStock(symbol);
  } 

そのため、新しい配置について通知されると、リスクトラッカーはこのクエリの結果を保持している制限と比較してテストします。

クラス RiskTracker...

  public void CheckForAlertsOnOrderPlacement(String symbol) {
      if (OverLimit(symbol))
          gateway.GenerateAlert(symbol);
      alertedStocks.Add(symbol);
  }

  private bool OverLimit(String symbol) {
      return stockLimit.ContainsKey(symbol) &&
             TotalExposure(symbol) > stockLimit[symbol];
  }

取引が執行されると、再びリスクトラッカーが証券取引所によって呼び出される必要があります。トラッカーは再び現在の総エクスポージャーを確認し、アラートをキャンセルする必要があるかどうかを判断します。

クラス StockExchange...

  public void Execute(Order o) {
      outstandingOrders.Remove(o);
      ServiceLocator.RiskTracker.CheckForCancelledAlerts(o.Stock);
  } 

クラス RiskTracker...

  public void CheckForCancelledAlerts(String symbol) {
      if (alertedStocks.Contains(symbol) && !OverLimit(symbol))
          gateway.CancelAlert(symbol);
  } 

図5：リクエスト/レスポンスを使用して、リスク制限を超える注文の配置がアラートをトリガーする方法を示すシーケンス図。

では、イベントコラボレーションを使用する場合を見てみましょう。重要な違いは、リスクトラッカーを追加しても、既存のコンポーネントに変更を加える必要がないことです。代わりに、既存のコンポーネントが公開するイベントをリスニングするようにリスクトラッカーを構築します。

クラス RiskTracker...

  public RiskTracker() {
      stockPosition = new Dictionary<string, int>();
      stockLimit = new Dictionary<string, int>();
      MessageBus.SubscribeToOrders(delegate(Order o) {
                                       handleOrderPlaced(o);
                                   });
      MessageBus.SubscribeToExecutions(delegate(Order o) {
                                           handleExecution(o);
                                       });
  } 

トラッカーは、ポジションを追跡するためのデータ構造も必要とします。エクスポージャーを判断するために証券取引所にクエリを実行することはないためです。

取引が行われると、トラッカーはイベントをピックアップします。それに応答して、ポジションのコピーを更新し、制限を超えているかどうかを確認します。

クラス RiskTracker...

  private void handleOrderPlaced(Order order) {
      if (!stockPosition.ContainsKey(order.Stock))
          stockPosition[order.Stock] =  0;
      stockPosition[order.Stock] += order.Volume;
      checkForOverLimit(order);
  } 

  private void checkForOverLimit(Order order) {
      if (OverLimit(order)) MessageBus.PublishAlertPosted(order);
  }
  private bool OverLimit(Order order) {
      return stockLimit.ContainsKey(order.Stock) &&
             stockPosition[order.Stock] > stockLimit[order.Stock];
  }

イベントコラボレーションを継続して使用するために、アラートが表示されたときにイベントを発生させます。それに応答してメールを送信したい場合は、そのイベントをリスニングするメールゲートウェイを作成できます。

実行イベントでは、ポジションのコピーを再度更新し、キャンセルを発生させる必要があるかどうかを確認します。

クラス RiskTracker...

  private void handleExecution(Order o) {
      bool wasOverLimit = OverLimit(o);
      stockPosition[o.Stock] -= o.Volume;
      if (wasOverLimit && !OverLimit(o))
          MessageBus.PublishAlertCancelled(o);
  } 

図6：イベントを使用して注文をするとアラートがトリガーされます。

この変更により、2つのインタラクションスタイルの重要な違いが明らかになります。

• リクエスト-レスポンスコラボレーションでは既存のコンポーネントを変更する必要がありましたが、イベントコラボレーションでは変更する必要がありませんでした。これは、既存のコンポーネントがすべての関連する変更情報をブロードキャストするためです。
• イベントコラボレーションでは、新しいコンポーネントに依存関係を追加しませんでした。
• イベントコラボレーションリスクトラッカーは、必要な状態をすでに含んでいるため、他のコンポーネントとさらに通信することなくアラートを判断できました。これにより、コンポーネント間の呼び出しの量が削減されました。これは、コンポーネントが別々のプロセスにある場合に重要になる可能性があります。 リクエスト-レスポンスコラボレーションで、呼び出しの一部として現在の総エクスポージャーを渡すことで同じ効果を実現できます。ただし、これは、証券取引所オブジェクトがリスクトラッカーが作業を行うために必要なデータを知る必要があることを意味し、2つのコンポーネント間の結合がさらに緊密になります。
• リスクトラッカーを追加する際に、イベントを使用して新しく追加された情報をブロードキャストし、全体的なコラボレーションにおいて優れた役割を果たせるようにしました。（そして実際に、それを使用してメールゲートウェイをトリガーしました。）リスクトラッカーによって公開されたイベントは、トラッカーの状態の変更に関連付けられていませんでした（ポジションの変更をブロードキャストしなかったため）。しかし、トラッカーがグローバルな知識に追加した新しい情報、つまりエクスポージャーが制限を超えているかどうか、に関連付けられています。

多くの人は、これらの違いは、リクエスト-レスポンスコラボレーションよりもイベントコラボレーションの方が結合が弱いシステムに関する根本的な違いであると考えるでしょう。私たちはそれほど確信していません。リクエスト-レスポンスコラボレーションでは、コンポーネントは、可能なリクエストのメニューとして表現されるインターフェースを介して相互に結合されます。しかし、イベントコラボレーションにも同じ基本的な結合が存在します。インターフェースがリクエスト呼び出しからイベントに変更されただけです。コンポーネントのイベントを変更すると、他のコンポーネントに影響が及ぶ可能性があります。

重要な違いは、コンポーネント間の通信フローがコンポーネント内に含まれなくなったことです。イベントコラボレーションを使用すると、証券取引所にリスクトラッカーにアラートを確認するタイミングを指示する必要がなくなります。この動作は、イブニングモデルによって暗黙的に発生します。

しかし、この暗黙的な動作には、負の側面があります。コンポーネントに別の変更を加えることを想像してみましょう。これまでのところ、注文は完全に実行されると想定していました。部分的な実行を処理するように証券取引所を変更してみましょう。

[Test]
public void ShouldCancelAlertIfParitalExecutionTakesBelowLimit() {
    StockExchange exchange = ServiceLocator.StockExchangeFor("TW");
    ServiceLocator.RiskTracker.SetLimit("TW", 2000);
    traderA.PlaceOrder("TW", 3000);
    Assert.AreEqual(1, ServiceLocator.AlertGateway.AlertsSent);
    Order theOrder = exchange.OutstandingOrders[0];
    exchange.Execute(theOrder, 1000);
    Assert.AreEqual(1, ServiceLocator.AlertGateway.CancelsSent);           
}
[Test]
public void ShouldNotCancelAlertIfParitalExecutionStillAboveLimit()
{
    StockExchange exchange = ServiceLocator.StockExchangeFor("TW");
    ServiceLocator.RiskTracker.SetLimit("TW", 2000);
    traderA.PlaceOrder("TW", 3000);
    Assert.AreEqual(1, ServiceLocator.AlertGateway.AlertsSent);
    Order theOrder = exchange.OutstandingOrders[0];
    exchange.Execute(theOrder, 999);
    Assert.AreEqual(0, ServiceLocator.AlertGateway.CancelsSent);
}

これを行うために必要な変更を見てみましょう。リクエスト-レスポンスコラボレーションの場合、部分的な実行を記録するように証券取引所を変更する必要があります。

クラス StockExchange...

  public void Execute(Order o, int volume) {
      o.ExecutedAmount += volume;
      if (o.IsFullyExecuted) outstandingOrders.Remove(o);
      ServiceLocator.RiskTracker.CheckForCancelledAlerts(o.Stock);
  }
  public void Execute(Order o) {
      Execute(o, o.Volume);
  }

class Order...

  public int ExecutedAmount {
      get { return executedVolume; }
      set { executedVolume = value; }
  }
  public bool IsFullyExecuted {
      get { return executedVolume == volume; }
  }
  private int executedVolume; 

リスクトラッカーへの参照がそこにあるため、部分的な実行ケースを考慮してリスクトラッカーを変更することを思い出させてくれます。ただし、トラッカーは証券取引所にクエリを実行することで未処理の合計を取得するため、実際にはリスクトラッカーをまったく変更する必要はありません。

イベントコラボレーションの場合を見ると、事態は少し複雑になります。証券取引所オブジェクトの基本的な変更は似ています。

クラス StockExchange...

  public void Execute(Order o, int amount) {
      o.ExecutedAmount += amount;
      MessageBus.PublishExecution(o);
      if (o.IsFullyExecuted) outstandingOrders.Remove(o);
  }
  public void Execute(Order o)  {
      Execute(o, o.Volume);
  }

ただし、リスクトラッカーへのリンクの表示がないため、変更を検討する必要があることを示唆するものはありません。実行された金額は注文のプロパティであるため、静的に型付けされたシステムであっても、すべてが正常にコンパイルされます。しかし、リスクトラッカーは、データの変更を適切にキャプチャしていないため、より明白な障害の兆候なしに、誤った情報を出し始めます。

これはもちろん、暗黙的な動作を持つシステムの固有の弱点です。見えないため、変更時にどのような変更を加える必要があるかがわかりません。ロジックの流れがコードで明示されていないため、デバッグも難しい場合があります。

これは、イベントコラボレーションを使用すると、一部の変更は容易になりますが、他の変更は難しくなることを示しています。2つの異なるスタイルの真の理解に基づいた経験を実際に捉えているものはあまり見ていないため、トレードオフの公平な全体像を把握するのは容易ではありません。