Domain Event Architecture
Everything you see in Scryer’s activity feeds, history, and notifications starts as a domain event. A single domain event model connects backend workflows, operational projections, notifications, and frontend-facing activity surfaces.
Diagram
Section titled “Diagram”
Why This Model Matters
Section titled “Why This Model Matters”Rather than pushing runtime payloads directly to the UI, Scryer persists a canonical event first and uses broadcasts only to signal that new sequences are ready. Every downstream surface — activity feeds, title history, notifications, library scan state, and job state — builds from that durable log.
That creates a clean split between:
- What happened: the stored domain event
- Who needs to react: projections, dispatchers, and live API surfaces
- How it becomes user-facing: activity rows, history tables, notifications, and operational views
This makes it straightforward to replay state after restarts, project different views from the same underlying event, and keep internal event shape separate from frontend presentation.
Related Concepts
Section titled “Related Concepts”- Domain Event Architecture — technical overview of Scryer’s backend design, of which domain events are a core component
- Context-Free Vs Context-Aware Release Parsing — detailed breakdown of the parsing subsystem whose results feed into the event pipeline
- Activity — the primary UI surface that exposes the live and historical event stream produced by this architecture
- System — instance health and job status views that surface the operational state of backend event processing