observability domain
owns how a running product answers questions about itself: what happened, where, why, and who is affected — from structured facts recorded as work runs.
why
after release, the running product is the only source of truth, and it can only answer questions it was designed to record. logs, traces, error codes, and alerts group because they form one evidence chain: structured facts make events searchable, correlation ids connect them, codes group them, and alerts turn them into action. remove any link and diagnosis falls back to guessing.
when to use
this domain owns a decision when the question is how a running product explains itself — structured logs, correlation ids, diagnostic error codes, metrics, and alerts. failure diagnostics as return values belong here too; how failures are orchestrated belongs to the workflow domain.
good and bad
bad
log: workflow failed
the message cannot identify the operation, affected fact, or causal chain. when a workflow fails at 2am, on-call has no context — they can't identify which channel or customer is affected, what caused it, or whether it's affecting others. diagnosis requires manual log searching across hours of unstructured text. mean time to recovery (MTTR) becomes hours.
good
event: workflow_run.failed, operation_id, workflow_run_id, diagnostic_code
structured domain facts make a running system searchable and repairable. logs show "purchase_workflow_run abc123 failed: provider_timeout on channel xyz". an on-call engineer can immediately identify affected customers, correlate with provider incidents, and take action. MTTR drops from hours to minutes. because every link in the evidence chain — structured facts, one correlation id, grouped codes, actionable alerts — is recorded by design, diagnosis stays a query instead of an archaeology session as the product and its traffic grow.