Executable UML: A Foundation for Model-Driven Architecture

Domains represent the different subject matters that we need to understand to build a system.

Definition: A domain is an autonomous, real, hypothetical, or abstract world inhabited by a set of conceptual entities that behave according to characteristic rules and policies.

For a given system, we first identify the several domains that make up the system as a whole. Generally, systems comprise domains such as an application, a bookstore for example; some implementation technologies, such as Java, HTML, a relational database, and XML; and some intermediate abstractions, such as a Web GUI, messaging, and workflow.

We then understand and model the application and intermediate abstractions using executable UML and apply various implementation technologies to realize the abstractions in the application and intermediate domains.

3.1.1 Domain Missions

Each domain should have a clear mission that drives the modeling work for that domain. Each domain therefore has a mission statement a sentence or two that's the systems development version of a domain's "elevator pitch." Figure 3.1 shows some domains for the online bookstore project, along with their mission statements.

Each domain has a set of conceptual entities that support the mission. An online bookstore has customers, orders, and the business rules governing their use, while a user interface domain involves windows and forms together with their entirely different set of operating policies about how those entities behave.

3.1.2 Domain Autonomy

Each domain forms a cohesive whole, semantically autonomous of other domains. This has a number of implications.

First, a conceptual entity is defined in exactly one domain. Orders and customers are part of the bookstore, while pages and icons are part of the user interface.

It is possible to have two entities with the same name in different domains, but they must mean different things. For example, a Table in HTML means "rows and columns," while a Table in a Furniture Manufacturing domain means "top and four legs."

Second, the conceptual entities in a domain require the existence of other conceptual entities in the same domain. An order makes little sense without a customer, and an icon requires a page on which to appear.

Third, the conceptual entities in one domain do not require the existence of conceptual entities in other domains. Customers and orders can exist without windows or icons, and windows and icons can exist without customers.

This is a most crucial idea: When we build a model of an online bookstore, that model will be complete and detailed about bookstore things. Done properly, the model will contain nothing that makes any assumption about a particular user interface, programming language, database, or other implementation technology.

3.1.3 Domain Replacement

Domain autonomy implies that one domain can be replaced with another. For example, a model of networking could be replaced by another one using different conceptual entities.

When you identify the different domains in a system, verify that each domain is truly cohesive and autonomous by mentally replacing a domain with another that has the same mission but a different set of conceptual entities.

It is good practice to plan a system so we can realize the application with different implementation technologies without needing to rethink, and remodel, the whole application. Though we usually intend to use one specific user interface, for example, we should think about the system as if it were likely that others could be used. Developers often face the problem of applying new technologies to existing applications: "Can this system be WAP^[1]-enabled in three months?"

^[1] WAP = Wireless Application Protocol: a sort of HTML for mobile phones

Similarly, we want to be able to reuse UI standards or messaging schemes, and to do so they need to be separate from the applications. The user interface design we use for the online bookstore, for example, could be applied in another context, in an accounting system or a mortgage system.

Complete autonomy of the domains is critical for rapid redeployment. Designing systems in terms of domains that can be replaced with others with the same mission but different conceptual entities improves the reusability of all domains. Domains are the largest units of reuse.

We can also identify other domains as generic, reusable services. The bookstore might need to track assignment of tasks to people in an organization. The assignment of tasks to people would be modeled as a Workflow domain without any knowledge of its use in the bookstore, and the Bookstore domain would make no reference to the conceptual entities in the Workflow domain. The same Workflow could then be used to track credit approval in a Mortgage system. Any necessary links between the two domain models are maintained separately from both domains.

Domain partitioning gives us the tools to represent the application subject matter separately from the implementation. It goes further, encouraging the construction of systems as layered abstractions.