Domain Modeling Fundamentals

Domain Modeling Fundamentals

Domain modeling is the bridge between the real‑world problem space and the software solution space. By capturing the essential concepts, relationships, and constraints of a business domain, developers can create a shared language that both stakeholders and technical teams understand. This course explores the core ideas behind domain models, how to identify conceptual classes, and the best practices for turning a model into a robust design.

Why Exclude Software Artifacts?

When building a domain model, it is crucial to keep the focus on real‑world concepts rather than implementation details such as windows, databases, or specific UI components. Including software artifacts creates a representational gap that can confuse stakeholders and obscure the true business intent.

• Irrelevant to the domain: Windows, tables, and other technical elements do not exist in the problem space.
• Clarity: A model that contains only conceptual classes is easier to discuss and validate with non‑technical participants.
• Flexibility: By avoiding premature design decisions, the model can evolve without being tied to a particular technology stack.

Understanding Conceptual Classes

A conceptual class represents an idea, thing, or object that exists in the real world. It is not a software class that implements behavior, nor is it a database row. Think of it as a noun that captures a meaningful entity within the domain.

• Examples: Customer, Order, Payment, Product.
• These classes become the foundation for later design artifacts, such as class diagrams and code structures.

Discovering Classes: The "Payment" Example

One effective strategy for uncovering hidden classes is to scan the scenario text for noun phrases that denote distinct concepts. In a retail store description, the phrase "Payment amount" signals that Payment is a separate conceptual class.

• Identify nouns and noun phrases.
• Ask: Does this noun represent a real‑world entity with its own attributes and behavior?
• Avoid mapping directly from database schemas; instead, let the language of the domain guide you.

Using Description Classes to Avoid Duplication

A description class separates the specification of an item from the item itself. This pattern is useful when multiple instances share the same set of attributes, preventing redundant data entry.

• For example, a ProductDescription class can hold the name, dimensions, and price, while individual Product instances reference that description.
• This approach reduces maintenance effort and keeps the model clean.

From Domain Model to Design Model

The transition from a domain model to a design model is not a simple copy‑and‑paste operation. Instead, domain concepts inspire the naming and structure of design classes, narrowing the representational gap between business language and code.

• Domain classes become the basis for design class names.
• Design classes may add methods, interfaces, and technical details that were absent in the domain model.
• Maintaining a clear lineage helps stakeholders trace requirements through to implementation.

Modeling Identifiers: When to Use a Class vs. an Attribute

Deciding whether an identifier like account number should be a class or an attribute depends on its real‑world nature. If the identifier represents a tangible concept (e.g., a physical account card) rather than just a piece of data, model it as a conceptual class.

• Do not automatically treat every numeric value as an attribute.
• Consider the semantics: Is the identifier something that can have its own relationships or behavior?
• When in doubt, ask domain experts whether the value stands alone as a concept.

Expressing Multiplicity: The Study Group Example

Multiplicity defines how many instances of one class can be associated with another. For a study group that always contains two to three students, the correct notation is StudyGroup 2..3 Student. This explicitly captures the business rule without needing additional constraints.

• Use precise ranges (e.g., 2..3) when the domain imposes strict limits.
• A generic 1..* range is too vague for such scenarios.
• Clear multiplicity aids both validation and later implementation.

Incremental Growth of a Domain Model

Attempting to capture every concept in a single, massive model often leads to missed details and stakeholder fatigue. An incremental approach allows the model to evolve, revealing hidden concepts and refining existing ones as new information emerges.

• Start with core entities and relationships.
• Iteratively add classes, attributes, and constraints.
• Validate each iteration with domain experts to ensure accuracy.

Key Takeaways

• Focus on real‑world concepts: Exclude software artifacts to keep the model pure.
• Identify conceptual classes: Look for nouns that represent tangible entities.
• Use description classes: Separate specifications from instances to avoid duplication.
• Bridge to design: Let domain concepts guide design class names and structures.
• Model identifiers wisely: Treat only true conceptual entities as classes.
• Specify accurate multiplicities: Reflect business rules directly in the model.
• Grow incrementally: Discover missing concepts through iterative refinement.

Further Reading and Resources

To deepen your understanding of domain modeling, explore the following resources:

• Martin Fowler’s Domain Model article
• UML Overview – Understanding Class Diagrams
• University of Maryland – UML Tutorial