A domain model is an object-oriented view of the business concepts an application needs to represent. Begin by identifying entities users recognize, their attributes, relationships, and rules. The model may first exist as a sketch or UML class diagram; it does not have to begin as Java code or a database schema. section 3.1.2
An online auction
An auction model might include Item, Bid, User, and Category. A Bid refers to an Item; an Item can have many bids and belongs to at least one Category. Categories can contain other categories. A User can have multiple addresses and billing details. These choices follow the business rules: if an item is auctioned only once, a separate auction entity is unnecessary. section 1.1.3 section 3.1.3
Use the class diagram to inspect the persistent auction classes and their relationships. It is a selected portion of the domain model, not necessarily every business concept. section 3.1.3
In Java, application logic works with instances of domain classes rather than directly with ResultSet rows and columns. Classes should encapsulate relevant state and behavior: a User, for example, can hold customer details and calculate shipping costs. Keep unrelated technical concerns out of these heavily reused classes. A simple application that only needs rows or existing stored procedures may not need a domain model. section 1.1.3 section 3.1.3 section 3.2
Persistence requires a separate mapping decision. Java classes and relationships do not automatically match SQL tables and columns: an Address can be a distinct Java class while its fields occupy several columns in a USERS table. Persistent classes can be mapped with JPA annotations or XML metadata; entity identity and primary keys also need handling. Mapping choices should preserve useful distinctions in the object model rather than flattening it merely to resemble SQL. section 1.2.1 section 3.0 section 5.0
