Building Management Context

Subdomain type: Core · Grounded in: User Stories BM-1 through BM-5

This page describes the design-time model of the Building Management context — the structural backbone of the platform that the live-data contexts decorate. Concrete APIs and storage are left as decisions for whoever builds this model.

The context models the physical reality being monitored: buildings, the rooms inside them, and the geometry that places those rooms in the 3D digital twin.

Ubiquitous Language

The Building Aggregate

We model Building as the single aggregate root, with Room as an entity that lives inside it. A Room has no meaning on its own — it is always created and changed in the context of its Building — which is why we draw the aggregate boundary around the Building rather than promoting Room to a root of its own.

classDiagram
    class Building {
        <<Aggregate Root>>
        +id
        +name
        +domain[] domains
        +Room[] rooms
    }
    class Room {
        <<Entity>>
        +id
        +name
        +Coordinates position
        +Dimensions dimensions
        +color
    }
    class Coordinates {
        <<Value Object>>
        +x
        +y
        +z
    }
    class Dimensions {
        <<Value Object>>
        +width
        +height
        +depth
    }

    Building "1" *-- "many" Room : contains
    Room "1" *-- "1" Coordinates : positioned at
    Room "1" *-- "1" Dimensions : sized by

Aggregate Root: Building

• A Building is associated with one or more domains (by name, the shared identifier). We model tenancy as a many-to-many association so that a structure can be shared across organizations without duplication — the shape story BM-2 asks for.
• Intended invariant: changes to a Room flow through its Building, so the aggregate is always saved as a coherent whole rather than as independently mutated rooms — the shape story BM-3 relies on when a staff member edits a room.

The aggregate as a whole, created in one coherent act with the system assigning identity, is what answers story BM-1.

Entity: Room

• A Room is identified within its Building.
• We deliberately keep only structural data on the Room — name, geometry. Live readings such as temperature and occupancy are not part of this model; they belong to the Telemetry contexts. This separation is a core design decision: it keeps the twin’s structure stable while readings change continuously.

Value Objects: Coordinates and Dimensions

Geometry is modelled as immutable, identity-less value objects. Two rooms sharing the same coordinates are not “the same place” — position is defined entirely by its values, which is exactly the value-object contract, and the one story BM-5 rests on.

Multi-Tenancy as a Domain Rule

A guiding decision for this context is that it should enforce tenancy without depending on the Identity & Access context at request time. The principal’s memberships arrive with the request (in the identity token), and a Building already records the domains it belongs to, so the rule can be evaluated entirely within this context.

sequenceDiagram
    participant C as Client
    participant B as Building Management
    C->>B: request buildings for a domain (with identity token)
    Note over B: check the domain is among the principal's memberships
    Note over B: select buildings associated with that domain
    B-->>C: authorized buildings

This is the intended shape of the rule — the one story BM-4 asks for — with the important property that answering it needs no call back to Identity & Access. How the check is wired and how buildings are queried are left open at the model level.

Relationships to Other Contexts

This context is meant to act as an upstream supplier to three downstream contexts. The model assumes that, when a Building comes into existence, the downstream contexts are given the baseline they need.