Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Domain Objects
Domain objects provide a common ground in which developers and users can meet and discuss the application. Domain objects represent concepts that are familiar to users and experts in a specific field of interest. We reason about a banking application using accounts, deposits, withdrawals, interest rates, and the like. In an airline booking application, we speak of reservations, airplanes, seats, destinations, schedules, and so on, as concepts that we will find in our software object model. Later, we develop the underlying structures and code and run scenarios for using the software. Given that users and experts are familiar with these domain concepts, they can discuss these aspects of the application easily. They feel comfortable manipulating these domain objects' information directly, and they understand the procedures for requesting their services.
For the developers, these domain objects are only the starting point for constructing a model of the domain and for developing the internal representations of these and additional concepts that will exist in the software machinery. Although the original, "common" concepts might not prove valuable in the executable system, they should be traceable through the design because they clearly express the stakeholders' understanding and issues surrounding the application.
Although not every software design effort starts by creating a domain model, most designs consist of certain objects that represent concepts familiar to experts in a particular domain supported by the application.
In an object-oriented application, the domain is made of information and services that the user needs, along with structures that relate the two (see Figure 3). For example, an inventory control system consists of monitoring the stock on hand (information), adding and removing the stock (services), and supporting policies for maintaining related stock (relations). These three aspects (information, services, and structures) apply to virtually all data-centric applications, and we use them to guide our development of objects that fulfill these roles.
The objects in a domain model embody the application's logic in their interactions. The domain model captures, at the most abstract level, the semantics of the application and its responses to the environment. It doesn't represent all concepts of a domain but only those that are necessary to support the application's intended scenarios of usage. The individual objects in the domain model hold the real, concrete responsibilities for responding to the user actions and for creating the new information that the user requires. If we are only describing a car and aren't building a model to execute on a computer, it's enough to construct a domain model that includes, among other things, a frame, an engine, a transmission, a steering wheel, a steering box, a steering column, wheels, and brakes. But when we must run it on a computer and design user interactions, we find that the domain of real-world race cars lacks many important behaviors. We need a richer set of objects and a richer domain—that of a simulated race car in a computer game. It is important to choose the right domain for your design problem and to recognize that objects designed to work in one domain won't easily slip into another, seemingly similar domain.
For example, in a race car simulation, the cockpit, racetrack, and competing cars must appear on the screen as visual images. What object from the domain of the real-world race car will do this? There isn't one! So for this specialized purpose, we must invent an object that presents the program images and captures user input: an interfacer.