Sub-domains

Working proposal

This page represents a working proposal, not a final definition. The sub-domains outlined here are an initial hypothesis for partitioning the hospitality domain. They will evolve as real-world PMS APIs are analysed and compared.

Introduction

When analysing Property Management System (PMS) APIs to infer a domain model, two related questions immediately arise:

Scope — What parts of a PMS fall within the scope of our model?
Partitioning — How can we divide that scope into manageable sub-domains?

The UHDM will ultimately be a single, interconnected model. However, it is impractical to visualise or reason about it as one monolith. Partitioning the model into sub-domains (or partitions) makes it easier to manage complexity, highlight areas of functional responsibility, and identify recurring design patterns between different systems.

Candidate sub-domains

The structure of many PMS APIs naturally suggests potential boundaries. Preliminary inspection indicates the following candidates:

Properties — Physical properties and their tangible resources, including guest rooms and other bookable spaces.
Reservations — The contractual relationships between bookers, guests, resources, services, and products, tied together by a universal calendar.
Rates — Sales prices and yield rules linked to reservations and availability; includes dynamic pricing, rate distribution, occupancy, and availability.
Profiles — The guests and companies who act as hospitality end-users and customers.
Services — Products and services offered by the property.
Accounts — Accounting ledgers for the property, customer accounts and folios, invoices and bills, individual bill items including payment items and deposits.

In addition, there are two orthogonal extensions that intersect several of these domains:

F&B (Food & Beverage) — Restaurant and outlet operations, point-of-sale orders (linked to Services), and bills (linked to Accounts).
M&E (Meetings & Events) — Group bookings, function spaces, availability, contracts, RFPs, and quotations.

First sketch (text representation)

The following schematic illustrates the proposed sub-domains, their core entities, and the orthogonal overlays.

+-------------------+       +----------------+       +----------------+
|  Properties       |       |  Reservations  |       |     Rates      |
|-------------------|       |----------------|       |----------------|
| Property          |       | Booking        |       | Rate Plan      |
| Room              |       | Reservation    |       | Rate           |
| Space             |       | Calendar       |       | Availability   |
+-------------------+       +----------------+       +----------------+

+-------------------+       +----------------+       +----------------+
|  Profiles         |       |  Services      |       |   Accounts     |
|-------------------|       |----------------|       |----------------|
| Guest             |       | Product        |       | Ledger         |
| Company           |       | Service        |       | Folio          |
| Contact           |       | Package        |       | Invoice        |
| Loyalty Program   |       | Add-on         |       | Payment Item   |
| Loyalty Membership|       |                |       | Deposit        |
+-------------------+       +----------------+       +----------------+

      [Orthogonal / Functional Overlays]
      POS / F&B → links to Services + Accounts
      M&E → links to Reservations + Services + Accounts
      Distribution → process over Rates + Reservations

(Diagram for conceptual illustration only — relationships are implicit rather than explicit.)

Mermaid representation (experimental)

The same conceptual layout expressed using Mermaid syntax. This format is being developed as part of UHDM’s visual modelling methodology, with the goal of producing consistent, machine-generated diagrams as the project evolves.

graph TB
  %% Layout direction: top-to-bottom
  %% Subgraphs represent proposed sub-domains

  subgraph Properties
    Property
    Room
    Space
  end

  subgraph Reservations
    Booking
    Reservation
    Calendar
  end

  subgraph Rates
    RatePlan["Rate Plan"]
    Rate
    Availability
  end

graph TB
  %% Layout direction: top-to-bottom
  %% Subgraphs represent proposed sub-domains

  subgraph Profiles
    Guest
    Company
    Contact
    LoyaltyProgram["Loyalty Program"]
    LoyaltyMembership["Loyalty Membership"]
  end

  subgraph Services
    Product
    Service
    Package
    AddOn["Add-on"]
  end

  subgraph Accounts
    Ledger
    Folio
    Invoice
    PaymentItem["Payment Item"]
    Deposit
  end

graph TB
  %% Orthogonal overlays (as annotations, not linked entities)
  note1["**POS / F&B** → links to Services + Accounts"]
  note2["**M&E** → links to Reservations + Services + Accounts"]
  note3["**Distribution** → process across Rates + Reservations"]

  classDef note fill:#f2f2f2,stroke:#aaa,stroke-dasharray: 3 3;
  class note1,note2,note3 note;

The Mermaid version demonstrates the direction for future domain model visualisation. As the format matures, all sub-domain diagrams will adopt a consistent machine-readable style.

Issues and open questions

Rate vs Rate Plan

Many PMSs distinguish between:

Rate Plan — the formal structure of pricing, policies, and availability rules.
Rate — a concrete price instance, often dynamic, tied to a Rate Plan for a specific date, inventory, or segment.

Both should probably exist as separate entities in UHDM, as most APIs treat them distinctly.

The term Order appears mainly in POS/F&B contexts. For the core UHDM (Accounts sub-domain) it may be preferable to model:

Invoice / Folio — the financial record.
Line Item / Bill Item — components of that record.

“Order” would then remain part of an orthogonal POS extension rather than a core financial entity.

Orthogonal extensions

F&B and M&E are treated as orthogonal functional overlays rather than independent sub-domains. They do not introduce new core entities but combine and extend existing ones.

Future direction

As additional PMS APIs are examined and their entities mapped, these partitions will be refined.
Future work will focus on:

Validating whether the proposed boundaries align with real-world system structures.
Identifying shared entities and cross-domain relationships.
Evolving the sub-domains into stable modules of the overall UHDM schema.

The aim is a set of clearly scoped, interoperable sub-domains that together describe the hospitality domain in a consistent, machine-readable way.