Chapter 3. Domains and Bridges

Building a system involves understanding many different subject matters and gluing them together to make a coherent whole. In an online bookstore, for example, we need to understand the application itself, the look and feel of a user interface, the details of user-interface screen layout using, say, HTML, messaging between computers, networking, and so on. In addition to these subject matters, we must also state how they relate to one another, so we can put them together into a complete system.

Each subject matter is a domain, capable of being understood and modeled using executable UML. We build one or more executable UML models for each domain.

Domains are semantically autonomous. For example, we can understand an online bookstore application without having to understand networking, and vice versa. But domains also depend on one another: The online bookstore makes assumptions about the existence of a networking domain and so places requirements on it. This assumption requirement pair is a bridge.

At implementation time, the models of each domain are woven together by specifying a set of join points between the models. The joining together of two domains is an implementation of a bridge. We take up this topic in Chapter 18: Model Compilers.

This chapter describes the concepts of domains and bridges, introduces a domain chart to visualize the relationships between them, and discusses how requirements relate to both systems and domains.