|Problem domain classes
|Define what qualifies an item as a problem domain class.
Problem Domain Classes
What qualifies an item as a problem domain class in object modeling?
In object-oriented analysis and design (OOAD), a problem domain class, often simply referred to as a domain class, is a conceptual class that represents the key components or entities in the system's problem domain. In essence, it's a direct representation of the real-world elements that the system is meant to model or manage.
- Real-World Correspondence: One of the primary qualifications for a problem domain class is that it corresponds to a real-world entity or concept within the system's problem domain. These entities can range from physical objects (like a "Book" in a library system) to abstract concepts (like an "Order" in an e-commerce system).
- Relevance: Not every real-world entity associated with the system needs to be represented as a domain class. To qualify, the entity must be relevant to the problem domain and the operation of the system. Entities that are incidental or peripheral to the system's functions are typically omitted.
- Rich Behavior: Domain classes often encapsulate both data and behavior, making them more than just simple data containers. A qualifying domain class will often embody significant behavior, or methods, that represent real-world actions or operations on the entity. For example, an "Account" domain class in a banking system might provide methods for depositing and withdrawing funds.
- Relationships: Domain classes frequently interact with each other, forming relationships that mirror those between the corresponding real-world entities. For a class to qualify as a domain class, it must be possible to define meaningful relationships with other domain classes. These relationships can be associations (e.g., a "Customer" class is associated with an "Order" class), aggregations (e.g., an "Order" class is composed of "OrderItem" classes), or inheritances (e.g., a "SavingsAccount" class inherits from a more general "Account" class).
- Persistence: Often, domain classes have a persistent state, meaning that they maintain their state over time. This is typically implemented using a database or some other form of long-term storage.
- Identity: Domain classes typically have unique identities. Even if two instances of a domain class have the same attribute values, they are considered distinct if they represent different real-world entities.
It's important to note that these qualifications are general guidelines rather than strict rules. The specific characteristics of a domain class can vary depending on the modeling methodology being used and the specific requirements of the system being designed. Regardless of these variations, however, the primary purpose of a domain class is always to accurately and effectively represent the key entities in the system's problem domain.
Question: What qualifies an object to become a problem domain class?
Answer: You already have one criterion:
The users must recognize the object. However, the object might be part of any number of other systems that the users work with.
Once again, the scope of the project becomes a crucial criterion. If the scope is unclear, then it is time to sit down, discuss the boundaries, and refine the scope statement. Get used to this process. Each new piece of information will force new questions and reveal new insights.
That is the nature of the process: constant enhancement and refinement.
Domain modeling is the task of discovering classes that represent those things and concepts.
Criteria for Problem Analysis Classes
A resource is something used by the actors. A resource may be acquired, maintained, used, possibly made and sold, and disposed of.
Using these simple criteria, the following items become good candidates for problem domain classes:
- Supplies and materials
- Records of transactions such as acquisition, sales, maintenance, and disposal
Does the criteria work?
To go back to the flower shop example used in a previous module, what kinds of things would be good flower shop problem domain classes?
| order takers, flower arrangers, drivers, bookkeepers, sales people
| Supplies and Materials
| flowers, paper, vases, wire, Styrofoam, greeting cards, and so on
| flower arrangements, gift items
| orders, shipments, sales receipts, customer invoices, supplier invoices
Key to ask here is, would the users recognize these objects? Would the flower shop use all these objects even if you never wrote any software?
Domain Classes - Quiz
Click the Quiz link below to take a short multiple-choice quiz on the problem analysis phase of the project life cycle.
Domain Classes - Quiz