事件协作

添加风险跟踪组件

到目前为止，我们已经了解了交易员和证券交易所使用这两种风格进行协作的不同方式。我们可以通过查看添加第三个组件在两种风格中的不同方式来进一步了解差异。

我们将添加的第三个组件是风险管理组件。它的工作是查看所有交易员对特定股票的未完成总量。

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

此外，风险管理系统需要在未完成总量超过预设限制时发送警报消息，并在低于限制时取消警报。

class StockRrRiskTester...

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

为了使这能够正常工作，风险管理系统需要参与订单的放置（这会增加风险敞口）和订单的执行（这会减少风险敞口）。

我们将从查看请求/响应场景开始，从放置开始。我们选择修改证券交易所对象的 submit 方法，以便在每次订单提交时提醒风险管理者。

class StockExchange...

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

我们可以在交易员身上进行此更改，但我们选择了交易所，因为它无论如何都需要这种依赖关系才能执行，因此我们可以避免从交易员到风险跟踪器的依赖关系。

为了让风险跟踪器确定总风险敞口，它会向相关证券交易所发出查询。

class RiskTracker...

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

因此，当被告知新的放置时，风险跟踪器会测试此查询的结果与它持有的限制。

class 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];
  }

当交易执行时，风险跟踪器再次需要被证券交易所调用。跟踪器再次检查当前的总风险敞口，并确定是否应该取消警报。

class StockExchange...

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

class RiskTracker...

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

图 5：显示放置超过风险限制的订单如何使用请求/响应触发警报的时序图。

现在让我们看看使用事件协作的情况。一个关键的区别是，添加风险跟踪器不需要我们对现有组件进行任何更改。相反，我们构建风险跟踪器来监听现有组件发布的事件。

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

跟踪器还需要数据结构来跟踪头寸，因为它不会查询证券交易所来确定风险敞口。

当交易被放置时，跟踪器会接收事件。作为响应，它会更新其头寸副本，并检查是否超过了限制。

class 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];
  }

为了继续使用事件协作，它会在出现警报时引发一个事件。如果我们想响应发送电子邮件，我们可以编写一个电子邮件网关来监听该事件。

在执行事件中，它再次更新其头寸副本，并检查是否需要引发取消。

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

现在让我们看看我们需要进行哪些修改才能做到这一点。对于请求-响应协作，我们需要修改股票交易所以记录部分执行。

class 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; 

因为那里有一个对风险跟踪器的引用，这有助于提醒我们考虑修改风险跟踪器以考虑部分执行情况。但是，由于跟踪器通过查询股票交易所获取总未完成量，因此我们实际上根本不需要修改风险跟踪器。

当我们查看事件协作情况时，事情变得有点棘手。对股票交易对象的基本修改是类似的。

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

但是，由于没有指示与风险跟踪器的链接，因此没有任何提示表明我们应该考虑修改它。由于执行数量是订单的属性，因此即使在静态类型系统中，一切仍然可以干净地编译。但是，风险跟踪器现在将开始提供不正确的信息，而不会出现更多明显的故障迹象，因为它没有正确捕获数据更改。

当然，这是任何具有隐式行为的系统的固有弱点，因为你看不到它，你就看不到修改它时需要进行哪些更改。它也可能难以调试，同样是因为逻辑流没有在代码中明确表示。

这表明使用事件协作使某些更改更容易，但另一些更改更难。很难获得对权衡的公平认识，因为我们还没有看到真正能捕捉到基于对两种不同风格的真正理解的经验的东西。