17.3 Implicit Bridging with Join Points

The explicit bridges asynchronous signals to and from external entities and bridge operations represent the absolutely required coupling between the bookstore domain and the rest of the system. Collectively, the explicit bridges represent the requirements made by the bookstore on other domains in the system.

Explicit bridges, however, represent only some of the interfaces between the bookstore domain and the rest of the system. Most of the bridging in the system is implicit. There is no explicit mention, not even anonymously, of how one domain links to another to be seen anywhere in the models.

17.3.1 Rationale for Join Points

Consider, for example, how the user interface connects to the bookstore domain. While the explicit bridges show certain signals from the Customer and the Shipping Clerk, there is nothing showing how the user interface gets the data to display on the screens.

We could add explicit bridges for example, a signal from the Shipping Clerk external entity to get the current list of pending Shipments. But that approach has two problems. First, it would make the Shipping Clerk state machine much more complex. Second, it would introduce an unnecessary and inappropriate coupling between the bookstore and a user interface domain.

Definition: A join point is a correspondence between domains that are created and maintained separately from the models of the two domains involved.

We present the examples of join points informally, using tables and graphical callouts to show the correspondences. The detailed mechanisms for realizing these bridges depend on the model compiler.

17.3.2 Class Class Joins

Classes in one domain may have counterparts in another domain. Consider the Inventory domain in Figure 17.3. The bookstore Products are instances of InventoryItem. Each time a Product is Shipped the Shipment Assigner creates a new instance of a Shipment Item a Consumption is created for the Inventory Item. Figure 17.8 shows how we can summarize the correspondences.

Figure 17.8. Correspondences between Bookstore and Inventory

With such a class-to-class join, an object in one domain corresponds to an object in the other domain.

Figure 17.9 shows correspondences between attributes, while Figure 17.10 shows correspondences between behaviors.

Figure 17.9. Correspondences between Attributes

Figure 17.10. Correspondences between Behaviors

These behavioral correspondences are implicit. Rather than writing signals to and from external entities and bridge operations directly in the bookstore models, we formally declare the correspondences listed above as part of the bridge between the two domains.

The real advantage of the Inventory domain now becomes clear: When a Shipment Item is created (a Consumption is created), that Consumption checks the quantity remaining in inventory and automatically reorders product. The whole issue of maintaining sufficient inventory in stock has been pushed down to the Inventory domain, simplifying the bookstore domain models.

17.3.3 Class Instance Joins

Other bridges are a bit more complex. Consider how certain user interface screens are populated. Unlike the bridge between Bookstore and Inventory, there is not a direct class-to-class mapping. There are no classes in the Web GUI that neatly correspond to classes in the Bookstore. The sets of classes in the two domains are quite distinct.

However, there are correspondences at the attribute level, as illustrated in the Author Detail screen of Figure 17.11. The structure of the screen can be represented in terms of User Interface domain (see Figure 17.2) things: a Page, a Datasheet with two Items, a Table with three Columns, and PresentationItems that link to other Pages.

Figure 17.11. Example UI Screen and Corresponding Bookstore Attributes

But the content of the screen can be represented in terms of Bookstore domain things: an Author (name, homepage, e-mail), Books (title and price), and Publisher (name).

Each user interface Page is different. Each has Presentation Items that correspond to different things in the bookstore. We cannot just say, as we did with the Inventory, that all instances of one class correspond to instances of another class. Instead, we need to write correspondences at the level of instances of things in the User Interface domain.

Figure 17.11 graphically illustrates the correspondences between User Interface things and Bookstore things in the context of a single object of a UI Page. The Page consists of sections: one datasheet and one table; the datasheet has two Items; the table has four columns and one row per Book written by the Author.

The effect of declaring this bridge is that whenever the Author Detail screen is displayed for a given author, the data for that screen is obtained from the application domain. We can define bridges like this for each of the screens displayed by the bookstore. For pages with editable fields and buttons, we can additionally map the buttons and fields to application signals and signal data.

The result is that the UI activity does not unnecessarily complicate the application domain models. The UI domain is also kept more generic than the application.