1.2. Domain Object Model
A term used frequently when describing JDO is domain object model. A domain model is an abstraction that identifies “real-world” entities and their relationships in the context of the business. Architects use the domain model to capture the subject matter expert's or domain expert's perspective of the system. For example, a broker or stock trader actually using a trading system identifies the logical structure in a trading system.
A domain model is not intended for developers and, as a result, is not supposed to include any implementation-specific details (for example, logging or security context).
This can be confusing because the static structure of a domain model is usually represented using UML class models. However, the domain model would normally never have a source-code representation. An entity from a domain model generally has multiple representations in different parts of a system. For example, a domain model for a trading system might show an account and a customer with a relationship between them, but the domain model represents the true real-world concepts of account and customer. In the working system, many manifestations of these real-world entities might exist; for example, a customer widget object might exist on the client side, a customer EJB or business object might exist in the middle tier, and a database record might be in the resource tier. A variety of other analysis, design, and implementation models may reflect how these domain entities are represented and manipulated by the system, but there is only one domain model.
Figure 1-1(a) shows a simple domain model in UML notation for a stock trading system used by a broker. Figure 1-1(b) shows another domain model for a system used by agents to process returned orders in UML notation with members expressed in the Java programming language. In general, the abstractions represented by the domain model are turned into one or more object models that can be expressed in a programming language and used by developers.
Figure 1-1a. A simple stock trading domain model.
Figure 1-1b. An order entry domain model with Java notation.
Based on the domain model, business requirements, and their own object models, developers agree that some of the entities represented in their application layer require persistence, in the sense that the data represented by these classes needs to be available beyond the life of the physical software process (like the JVM) in which they are being used. For example, the order, account, and customer information needs to be saved so that it can be accessed at a later time when the user checks the status. At the same application layer, other programming constructs might also require persistence – for example, log messages, security audit trails, user sessions, and so on.
This is where JDO comes in. It provides developers with a mechanism for transparent persistence.