17.2 Anonymous Explicit Bridges

Bridges"-->

17.2 Anonymous Explicit Bridges

A link to another domain is effected by actions that generate signals or synchronously invoke defined operations on an external entity. The domain to which the external entity refers remains anonymous.

17.2.1 External Entities

Each domain's models include a number of external entities. External entities are not domains themselves; rather, they act as anonymous proxies to other domains. This notion of anonymity is important: There are times when a domain requires something of some other domain for example, the bookstore needs signals to initiate activities but the models of the bookstore domain need to be independent of the methods by which those signals originate.

External entities are represented on the collaboration diagrams as boxes with the «external entity» stereotype or as the UML symbols for actors, stick figures. The collaboration diagram in Figure 17.4 shows the external entities that interact with the bookstore.

Figure 17.4. Bookstore Collaboration

17.2.2 Signals from External Entities

External entities can receive and generate signals. For example, the external entity Customer sends a signal checkOutByCreditCard to the ShoppingCart to check out the cart. We have already seen how signals from external entities initiate activities in the domain.

The bookstore models show only that some Customer requests to check out the Shopping Cart. It does not say how the Customer did this the Customer could do it by clicking a button on an HTML form, pressing a key on a touchtone phone, or the Vulcan mind-meld. From the perspective of the bookstore domain, it only matters that the Customer must somehow signal the Cart to be checked out.

(If while reading the last paragraph you have a strange sense of déjà vu that you read something strikingly similar back in Chapter 3: Domains and Bridges you're right. This is how we maintain domain separation.)

17.2.3 Signals to External Entities

The procedures can also send signals to external entities. For example, in the online bookstore, once the customer checks out, an attempt is made to charge the card. In the Credit Card Charge model shown in Figure 17.5, the procedure of state 1 generates a signal to the Credit Card Company external entity using the syntax shown in Figure 17.6.

Figure 17.5. Credit Card Charge Showing Explicit Bridges

Figure 17.6. Generating a Signal to External Entity CreditCardCompany

We use signals to external entities whenever the domain requires that a particular service be performed by another domain. In this case, the bookstore requires that some other domain determine whether a particular credit card charge can be approved so that an Order can be processed. Other such explicit signals to external entities notify the Delivery Company that a Shipment is ready to be picked up, notify the Shipping Clerk that an Order is ready to pack, and notify the Customer whether a charge was approved or declined.

17.2.4 Bridge Operations

Signals are asynchronous: An action procedure that sends signals completes after the signals have been sent. The consequences of those signals the actions of the receiving states' procedures or external entities take place concurrently or subsequent to the completion of the sending procedure.

There are other times when a procedure requests a service from another domain as part of the procedure. For these situations, a procedure action synchronously invokes a bridge operation on an external entity.

Definition: A bridge operation is an operation defined on an external entity and implemented in another domain.

Like external signal generation, a bridge operation is associated with an external entity. The external entity defines the name of the operation and its signature.

For example, suppose that the bookstore uses an external package to compute sales tax on orders. The calculation is not part of the bookstore domain but is provided by some other domain. Define an external entity to represent the sales tax package (SalesTax) and compute the tax synchronously using a bridge operation, as seen in Figure 17.7.

Figure 17.7. A Bridge Operation Calling an External Package

Bridge operations may return values. In the example above, the bridge computeSalesTax returns a Currency value of the sales tax.

17.2.5 Synchronous or Asynchronous Bridging?

External signals and bridge operations both involve activity outside the domain under study. A bridge operation is synchronous the invoking action waits for completion of the bridge operation. An external signal is sent and the receiving domain does its work independently of the sender. When to use one or the other?

The general rule is that the actions of state procedures should not require an immediate result within the domain. For example, a request to approve a credit card charge must wait for the bank to approve or decline the charge, and we model this asynchronously. On the other hand, a sales tax calculation that can be carried out as soon as the request is made can be modeled synchronously.

Why don't we just make the bookstore Product a subclass of Inventory Item?

We could. But that, like inheritance, would make the bridge between the two domains explicit.

The concept of domain partitioning is to keep subject matters and their models separate. A model compiler might use inheritance as a mechanism to implement a join between two domains, but that is not a requirement.

Explicit bridging is an object-oriented approach. Implicit joins are an aspect-oriented approach.