3.3 Bridges

Domains are autonomous, but they rely on the existence of other domains. For example, an online bookstore domain can be modeled without reference to any mechanism that selects the item the customer wants or the desired quantity. The user interface mechanism could be HTML, voice recognition software, or some other yet-to-be-invented technology.

We implicitly assume that there is some way to determine the specific items and quantities of them to add to the order. This implicit assumption in turn embodies requirements that somehow the customer can communicate with the bookstore application. A bridge exists between the bookstore domain and some other domain that can satisfy the requirement implied by the assumption.

Definition: A bridge is a layering dependency between domains. One domain makes assumptions, and other domains take those assumptions as requirements.

These assumption requirement pairs form an asymmetric dependency: The bookstore needs a user interface to do its job, but the user interface domain does not rely on the online bookstore application for its existence. We maintain domain autonomy using the bridge as intermediary.

A domain makes assumptions about a bridge, and the bridge then places requirements on another domain. For example, the bookstore has a requirement to find out the requested item and quantity. Only when we decide to communicate with users specifically using menus does the bridge place the requirement on a specific user interface domain that supplies the menus. Hence, we think of a bridge as having two parts. The first part contains a set of assumptions that one domain makes, and the second part contains a set of requirements placed on a domain.

Multiple domains may place requirements on their respective bridges, all of which could be satisfied by a single domain. For example, the application may assume the existence of a scheme to communicate with the credit card company, while the web browser assumes the ability to communicate with a host. Both requirements can be accomplished with a single messaging domain. Hence, a bridge can have many domains that make assumptions about it and a single domain that satisfies those requirements.

Each domain is represented as a UML package, and each bridge is shown as a dotted dependency line between them.

Some domains are groupings of other subject matters into a single whole with a single united interface. We show this situation by placing folders inside a larger folder. In Figure 3.2, the model compiler has a single interface used by messaging, the Web GUI, and the bookstore. In turn, the model compiler uses Java, Solaris, Oracle, and Xerces.

Figure 3.2. Domain Chart

Some domains are not modeled, but are instead already realized as code. These domains are stereotyped «realized». (The «» indicate a stereotype [i.e., a special form or use of some UML element]. These symbols are called guillemets ["ghee-yu-may," with a hard G].)

The domain chart is very high level, providing only a name for each domain. To flesh out the definition of the domain, build a mission statement for the domain that will drive the modeling of that domain, as shown in Section 3.1.1: Domain Missions. Note how the domain mission statements are very short only a phrase or a few sentences. The objective is to communicate information succinctly, not to be textual representations of the models.

As soon as an assumption is identified, add it to the end of the domain's mission statement. If you can identify the bridge that can satisfy the assumption, allocate the assumption to the appropriate bridge, as in Figure 3.3.

Figure 3.3. Domain Mission Statement, Including Bridge Descriptions

Bridges represent flows of assumptions and requirements, not flows of control.

Many systems carry out their functions only in response to some user request, and as a consequence, control flows from the user interface domain to the application. A web-based online bookstore application, for example, might begin by asking the user for the account number and password, and then move on to a screen for buying and selling. Nothing is done until the user makes a request, except possibly a time-out if there is no activity.

The customer log-in screen, however, exists only because the application needs it. There is an assumption requirement dependency between the application, which needs customers to log in, and the appearance of specific menus and buttons that allow the customer to do so.

As the project proceeds, especially once modeling has begun, it is critical to reconcile the various clients' assumptions to ensure they form a complete set of requirements on specific domains. See also the discussion in Section 2.1.3: Iterating the System Model.

To the extent that domain-level requirements have been identified, these requirements are more specific forms of the general requirements identified on a bridge. Domain-level requirements for the domain therefore "belong" with the bridge to the domain in question.