# DDR-0008: E27 Message Dispatch Key Is (domain, command)

Status: Accepted  
Date: 2025-12-22  
Related ADRs: ADR-0007 (E27 Layering), ADR-0012 (Inventory-Driven API Surface)

## Context

E27 uses JSON APIs grouped by domain. Within each domain, individual commands have
distinct request/response shapes. A dispatch mechanism is needed that is equivalent
to the Elk M1 opcode-based dispatch model, but aligned with E27’s JSON structure.

## Decision

Inbound E27 JSON messages are dispatched using a two-level key:

- domain: the top-level JSON key identifying the API family (e.g., "zone", "area")
- command: the single operation key within the domain object (e.g., "get_status")

Dispatcher rules:
- Exactly one recognized domain key must be present at the top level, unless a
  specific message type explicitly allows multiple domains (future extension).
- Within the domain object, exactly one recognized command key must be present.
- If no recognized domain/command is present, dispatch returns an error result with
  a clear message (no silent fallback).

## Rationale

- Mirrors M1’s opcode→handler model while respecting E27’s domain/command design
- Allows strict validation and clear errors per command
- Enables incremental domain coverage without rewriting dispatcher logic

## Consequences

- Handler registries are keyed by domain and command
- Messages with multiple candidate domains/commands must be explicitly handled or rejected
- Unknown domain/command paths must produce deterministic error results
