Domain Model

A domain model is a visual representation of conceptual classes or real-situation objects in a domain. This model is the most important and classic model in OO analysis as it illustrates noteworthy concepts in a domain. It can act as a source of inspiration for designing some software objects and will be an input to several design models.

Bounded by the requirements currently under development, the domain model can be evolved to show related noteworthy concepts. The related use case concepts and insight of experts will be input to its creation. The model can in turn influence operation contracts, a glossary, and the Design Model, especally the software object of the Design Model.

Identifying a rich set of conceptual classes is at the heart of OO analysis. If it is done with skill and short time investment, it usually pays off during design, when it supports better understanding and communication.

How to Create a Domain Model
Use terms that are specific to the domain:
 * Use the existing names in the territory. For example, if developing a model for a library, name the customer a "Borrower".
 * Exclude irrelevant or out-of-scope features. For example, in the Monopoly domain model, cards are not used, so don't show a Card in the model for that iteration.
 * Do not add things that are not there.

Some software systems are for domains that find very little analogy in the natural or business domains, e.g. telecommunications. Yet it is still possible to create a domain model in these domains. It requires a high degree of abstraction, listening carefully to the core vocabulary and concepts that domain experts use.

Bounded by the current interation requirements under design:
 * 1) Find the conceptual classes
 * 2) Draw them as classes in a UML class diagram
 * 3) Add associations and attributes

Sketching a Class Diagram
When sketching a domain model, keep the bottom and right sides of the class boxes open. This makes it easier to grow the classes as we discover new elements. Spread them out on a whiteboard.

If someone wants the model maintained and updated with new discoveries, redraw the whiteboard sketch within a UML CASE tool. But ask yourself "who is going to use the updated model, and why?". If there isn't a practical reason, don't bother. Often the evolving domain layer of the software hints at most of the noteworthy terms, and a long-life OO analysis domain model doesn't add value.

Find the Conceptual Classes
There are three strategies to find conceptual classes:
 * 1) Reuse or modify existing models. This is the first, best, and usually easiest approach. There are published, well-crafted domain models and data models (which can be modified into domain models) for many common domains, such as inventory, finance, health, etc. Example books are  ref 1,  ref 2, and  ref 3
 * 2) Use a category list.
 * 3) Identify noun phrases.

Category list: A list of candidate conceptual classes. The following table contains many common categories that are usually worth considering, with an emphasis on business information system needs.

Noun phrase identification: Identify the nouns and noun phrases in textual descriptions of a domain, and consider them as candidate conceptual classes or attributes. Care must be applied with this method. A mechanical noun-to-class mapping isn't possible, and words in natural languages are ambiguous. Still this is another source of inspiration.

The fully dressed use cases are an excellent discription to draw from for this analysis. Some of those found are candidate conceptual classes, some may refer to conceptual classes that are ignored in this iteration, and some may be simply attributes of conceptual classes.

Attributes vs. Classes
Perhaps the most common mistake when creating a domain model is to represent something as an attribute when it should have been a conceptual class.

Guideline: If we do not think of some conceutpal class X as a number or text in the real world, X is probably a conceptual class, not an attribute.

Example: Should destination be an attribute of Flight, or a separate conceptual class Airport? In the real world, a destination airport is not considered a number of text, it is a massive thing that occupies space. Therefore, Airport should be a concept.

Include Receipt
Receipt is a noteworthy term in some domains, but perhaps it's only a report of a sale and payment, and thus duplicate information. Should it be in the domain model?
 * In general, showing a report of other information in a domain model is not useful since all its information is derived or duplicated from other sources. This is a reason to exclude it.
 * On the other hand, it has a special role in terms of the business rules: It usually confers the right to the bearer of the (paper) receipt to return bought items. This is a reason to show it in the model.

For example, since returns are not being considered in this iteration, Receipt will be excluded. During the iteration that tackles the Handle Returns use case, it will be included.

Model Description Classes
A description class contains information that desribes something else. It does not represent an Item, it represents a description of information about items. It turns out that the need for description classes is common in many domain models. This pattern is also called Item-Descriptor. For example, a ProductDescription that records the price, picture, and text description of an Item.

Add a description class when:
 * There needs to be a description about an item or service, independent of the current existence of any examples of those items or services.
 * Deleting instances of things they describe results in a loss of information that needs to be maintained, but was incorrectly associated with the deleted thing.
 * It reduces redundant or duplicated information.

The need for description classes is common in sales, product, and service domains. It is also common in manufacturing, which requires a description of a manufactured thing that distinct from the thing itself.

Associations
It's useful to find and show associations that are needed to satisfy the information requirements of the current scenarios under development, and which aid in understanding the domain.

Associations worth noting usually imply knowledge of a relationship that needs to be preserved for some duration.

Consider including the following associations in a domain model:
 * Associations for which knowledge of the relationship needs to be preserved for some duration ("need-to-remember" associations).
 * Associations derived from the Common Associations List.

Name an association based on a ClassName-VerbPhrase-ClassName format where the verb phrase creates a sequence that is readable and meaningful.

Common Associations List:

^ Category ^ Examples ^
 * A is a transaction related to another transaction B | CashPaymentSale, CancellationReservation |
 * A is a line imte of a transaction B | SalesLineItemSale |
 * A is a product or service for a transaction (or line item) B | ItemSalesLineItem, FlightReservation |
 * A is a role releated to a transaction B | CustomerPayment, PassengerTicket |
 * A is a physical or logical part of B | DrawerRegister, SquareBoard, SeatAirplane |
 * A is physically or logically contained in/on B | RegisterStore, ItemShelf, SquareBoard, PassengerAirplane |
 * A is a description for B | ProductDescripitonItem, FlightDescriptionFlight |
 * A is known/logged/recorded/reported/captured in B | SaleRegister, PieceSquare, ReservationFlightManifest |
 * A is a member of B | CashierStore, PlayerMonopolyGame, PilotAirline |
 * A is an organizational subunit of B | DepartmentStore, MaintenanceAirline |
 * A uses or manages or owns B | CashierRegister, PlayerPiece, PilotAirplane |
 * A is next to B | SalesLineItemSalesLineItem, SquareSquare, CityCity |

Attributes
Include attributes that the requirements suggestsor imply a need to remember information. E.g. a receipt (whcih reports the information of a sale) in the Process Sale use case normally include a data and time (''dateTime' ' attribute), the store name and address, and the cashier ID, among other things.

The total attribute in the Sale can be calculated or derived from the information in the SalesLineItems. When we want to communicate that 1) this is a noteworthy attribute, but 2) it is derivable, we use the UML convention / symbol before the attribute name.