事件協作

新增風險追蹤元件

到目前為止，我們已瞭解交易員和股票交易所使用這兩種樣式進行協作的不同方式。我們可以進一步透過觀察在兩種樣式中新增第三個元件的方式不同，來了解兩者的差異。

我們將新增的第三個元件是風險管理元件。它的工作是查看特定股票的所有交易員的總未完成量。

類別 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);
  } 

為了讓此系統運作，風險管理系統需要參與訂單配置（會增加風險曝險）和訂單執行（會減少風險曝險）。

我們將從要求/回應場景開始，從配置開始觀察。我們已選擇修改股票交易所物件的 submit 方法，以便在每次訂單提交時向風險管理員發出警示。

類別 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：下單觸發警示，並使用事件。

這個修改帶出兩種互動樣式之間一些重要的差異。

• 我們不需要修改現有元件以進行事件協作，但我們需要修改請求-回應協作的元件。值得注意的是，這在很大程度上是因為現有元件會廣播所有相關的變更資訊
• 我們沒有為事件協作的新元件新增任何依賴關係。
• 事件協作風險追蹤器能夠在不與其他元件進一步通訊的情況下決定警示，因為它已經包含必要的狀態。這減少了元件間呼叫的數量，如果元件在不同的程序中，這可能會很重要。你可以透過將目前的總曝險作為呼叫的一部分來達成請求-回應協作的相同效果，但這表示證券交易所物件需要知道風險追蹤器需要什麼資料才能執行其工作，這會進一步耦合這兩個元件。
• 當我們新增風險追蹤器時，我們確保使用事件來廣播其新增加的資訊，以便它能在一般協作中成為一個好的公民。（而且我們確實使用它來觸發電子郵件閘道器。）請注意，風險追蹤器發布的事件並未與追蹤器的狀態變更綁定（因為我們沒有廣播部位的變更），而是與追蹤器新增到全球知識的新資訊綁定，無論曝險是否超過限制。

許多人會認為這些差異基本上是關於一個系統，其 事件協作 的耦合比 請求回應協作 少。我們不確定。在 請求回應協作 中，元件透過其介面彼此耦合，表示為可能的請求功能表。但 事件協作 中存在相同的基本耦合，只是介面已從請求呼叫變更為事件。如果我變更元件的事件，它仍會對其他元件產生影響。

關鍵差異在於元件之間的通訊流程不再包含在元件內部。使用 事件協作，我們不必讓股票交易所告訴風險追蹤器何時應該檢查其警示。此行為會透過事件模型隱含地發生。

但這種隱含行為會帶來負面影響。讓我們想像對我們的元件進行另一項變更。到目前為止，我們假設訂單會全部執行。讓我們變更我們的股票交易所，以處理部分執行。

[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);
  }

類別訂單...

  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);
  }

然而，由於沒有風險追蹤器連結的指示，因此沒有任何建議表示我們應該考慮修改它。由於已執行金額是訂單的屬性，因此即使使用靜態型別系統，所有內容仍會乾淨地編譯。但風險追蹤器現在會開始提供不正確的資訊，而沒有任何更明顯的失敗跡象，因為它沒有適當地擷取資料變更。

當然，這是任何具有隱含行為系統的固有弱點 - 由於您看不到它，因此您不知道在修改它時需要進行哪些變更。這也可能很難除錯，原因在於邏輯流程沒有在程式碼中明確說明。

這顯示使用事件協作會讓某些變更變得更容易，但其他變更則更困難。要公平地了解取捨並不容易，因為我們尚未看到真正能根據對兩種不同風格的實際理解來掌握經驗的內容。