UX Design · Study deck
IoT Design Patterns: Responsibility Boundaries
A building light can fail after one part changes because no one knows which part owns state.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- define component boundaries that hide implementation details but expose the evidence a system needs
- explain when Gateway, Digital Twin, Command, and Observer patterns fit an IoT design problem
- combine patterns without hiding ownership, stale state, duplicate commands, or event-ordering problems
- use model-driven design when repeated deployments need consistent generated artifacts
Major section
Start Simple
The team needs to know which part owns the command, which part stores state, and which part reports the result.
- A pattern is useful when it makes that duty clear.
- A gateway is a device or service that joins one system boundary to another.
- A design pattern is a reusable way to assign a job.
- It sits at a boundary.
Major section
Start Simple (continued)
A gateway may translate and buffer.
- A digital twin may hold a known view of device state.
- A command record may track an asked-for action.
- An observer may pass an event to listeners.
- Each choice needs a clear owner, input, output, fault state, and test.
Major section
Overview: Patterns Assign Responsibility
IoT patterns are useful when they make a responsibility testable.
- A gateway is not just a box between devices and the cloud.
- A digital twin is not just a database row.
- A command is not just a function call.
- An observer stream is not just a list of subscribers.
Major section
Overview: Patterns Assign Responsibility (continued)
A room twin may represent occupancy, freshness, confidence, and actuator relationships.
- Each pattern should clarify who owns state, what crosses the boundary, what fails visibly, and what support can inspect.
- It may need commands because physical actions must be accepted, rejected, retried, or audited.
- A command handler may validate authorization and preconditions before changing ventilation.
Major section
Overview: Patterns Assign Responsibility (continued)
It may need observers because dashboards, logs, alerts, and support views should receive events without becoming hidden controllers.
- Together,: Light / LDR and: Sensors frame the overview: patterns assign responsibility claim: pattern review starts by separating component responsibilities, then checks whether interfaces, data flow, automation, and user-facing outputs have explicit owners.
- For a building-control system, a gateway may translate Modbus, BACnet, Zigbee, or BLE data into MQTT topics.
- The pattern record should also show rejected alternatives.
Major section
Practitioner: Make Contracts Concrete
Pattern reviews should leave behind contracts that engineers and support teams can test.
- For a gateway, that means the device-side protocol, normalized field names, units, timestamp source, queue limit, retry policy, and local fallback rule.
- For a twin, it means desired state, reported state, last update time, confidence, relationship fields, schema version, and authority for conflict resolution.
- The pattern choice should explain why the selected option fits the user promise and operating burden.
Major section
Boundary Drift in Models
A gateway and cloud service may both rewrite device state.
- A command queue and direct API may both actuate the same relay.
- A digital twin may store desired state while the dashboard treats it as measured state.
- An observer may publish an event that one subscriber treats as a fact and another treats as a command.
Major section
Boundary Drift in Models (continued)
The technical cause is usually a missing authority rule.
- Telemetry, state, command intent, command result, alert, and support diagnosis are different facts even when they share a device ID.
- A robust pattern model separates them before code is written.
- Each one needs a timestamp, version, and failure label.
- Under the hood, the safest pattern combinations are traceable.
Major section
Boundary Drift in Models (continued)
A source model can generate MQTT topics, JSON Schema payloads, OpenAPI documentation, dashboard labels, test fixtures, or support checklists.
- A sensor event can be followed through topic, schema, gateway log, twin update, observer event, dashboard render, and support record.
- A command can be followed from issuer, permission check, precondition, queue, actuator acknowledgement, retry decision, and user feedback.
- Version contracts: version schemas, events, commands, and generated artifacts so old devices and new services can coexist safely.
Deck summary
Key takeaways
The team needs to know which part owns the command, which part stores state, and which part reports the result.
- A gateway may translate and buffer.
- IoT patterns are useful when they make a responsibility testable.
- A room twin may represent occupancy, freshness, confidence, and actuator relationships.
- It may need observers because dashboards, logs, alerts, and support views should receive events without becoming hidden controllers.
Retrieval practice
Recall check
UX Uma says: answer from memory, then check your reasoning.
Q1A team chooses a gateway, digital twin, command handler, and observer stream for shared building controls. Which pattern record makes the boundary decision reviewable?
Show answer
Answer: A A reviewable pattern decision ties the product promise, boundary, selected pattern, rejected alternative, interface contract, state or command behavior, failure mode, evidence, owner, open issue, and change condition together before implementation.
Print reference
Answers
Answer key.
- A · A reviewable pattern decision ties the product promise, boundary, selected pattern, rejected alternative, interface contract, state or command behavior, failure mode, evidence, owner, open issue, and change condition together before implementation.