Domain models, data models, and business rules

Updated 28 Oct 2026

•
Domain and conceptual models
- •
  Domain -> the problem area being studied.
- •
  Domain model
  - •
    captures relevant concepts, relationships, rules, and events.
  - •
    helps stakeholders understand the area before deciding how to implement software.
- •
  Complementary perspectives in the supplied materials
  - •
    Larman's object-oriented analysis view
    
    •
    represents real-world conceptual classes, attributes, and associations.
    
    •
    often uses UML class notation without software operations.
  - •
    Broader domain-knowledge view
    
    •
    attributed in the supplied excerpt to Sommerville (2016).
    
    •
    also encompasses policies, procedures, and events.
    
    •
    a collection of class diagrams is therefore not the whole domain model
- •
  a conceptual class represents a domain concept, not automatically a software class or database table
  - •
    Symbol -> its name or notation.
  - •
    Intension -> what the concept means.
  - •
    Extension -> examples/instances
- •
  to build a model:
  1. 1.
    set the domain boundary and purpose
  2. 2.
    identify conceptual classes from the domain vocabulary and scenarios
  3. 3.
    draw relevant associations and add attributes
  4. 4.
    validate the meaning and rules with domain stakeholders
- •
  Class or attribute?
  - •
    consider a class when something has its own identity and relationships rather than being just a number or text value.
  - •
    this is a guideline, not an automatic rule.
- •
  Classes without attributes
  - •
    a class may have no attributes yet.
  - •
    its role in the domain can matter before persistent data is specified
- •
  POS example
  - •
    Sale, Payment, and Item are domain concepts.
  - •
    their associations explain the domain
  - •
    they do not yet prescribe tables or screen designs
•
Domain model versus data model
- •
  a domain model emphasizes meaning: what exists and how concepts relate.
- •
  a data model emphasizes how information is represented and, in a database design, persisted.
- •
  an ERD depicts entities, attributes, and relationships using a chosen notation.
  - •
    attributes may be keys, simple, composite, multivalued, or derived.
  - •
    Cardinality -> one-to-one, one-to-many, or many-to-many.
  - •
    specify participation/optionality too
  - •
    connecting lines carry relationship meaning according to the notation.
- •
  Model levels and notation
  - •
    an ERD may be conceptual, logical, or physical.
  - •
    not every ERD is an implemented schema.
  - •
    not every UML class diagram is a domain model.
- •
  compare this “what exists” view with the process architecture and flow view of "what happens"
- •
  Add a paired example: conceptual Sale-Payment-Item associations beside a small ERD, showing which persistence details are added rather than assumed.
•
Rules, constraints, assumptions, and dependencies
- •
  keep these distinct in requirements analysis
- •
  Business/domain rules govern how the business works.
  - •
    example: reject an application when its credit score is below the specified threshold.
  - •
    Successive-discount example
    
    •
    apply $20\%$ off, then $10\%$ off the reduced price.
    
    •
    result: $2000(0.8)(0.9)=1440$ .
    
    •
    this is not a combined $30\%$ discount.
- •
  Constraints are imposed limits on a solution or its development.
  - •
    categories in the material: resource, technological, external, operational, and performance constraints.
  - •
    examples include a fixed budget/deadline, minimum staff qualifications, or a required server capacity.
  - •
    Source and rationale
    
    •
    customer needs, regulations, existing systems, and operating conditions can all impose constraints.
    
    •
    record where each constraint comes from and why it applies.
- •
  Assumptions are provisional statements accepted for planning until confirmed, not proven facts.
  - •
    example: intended users have the expertise needed to perform a particular coordination task.
  - •
    record an owner, a validation plan, and the consequence if an important assumption fails.
  - •
    Classification caution
    
    •
    “Supports the latest OS” or “requires 8 GB RAM” may be a requirement or constraint once agreed.
    
    •
    classify a statement by its status, not just its wording.
- •
  Dependencies are things another component or activity needs to work.
  - •
    Web service example
    
    •
    may depend on server availability and network access.
    
    •
    describe offline behavior separately if relevant.
  - •
    Program example
    
    •
    may depend on a language/library's sorting implementation.
    
    •
    that implementation detail is not itself a business rule.

Linked references 1

information-systems-polban

◌ Explore connections in Graph view

Domain models, data models, and business rules

Domain and conceptual models

Domain model versus data model

Rules, constraints, assumptions, and dependencies

Linked references 1