ADR-0008 records the read-projection design: one rebuildable store shared by the Event Subscriber (writer) and projection-api (reader) as one CQRS bounded context (reconciled with §8.5), idempotency + rebuild from the notification log (no OpenZaak access, §8.1), the deferred bsn/naam, and the new EF Core + Npgsql dependency. Add a demo-script entry walking the OZ→NRC→subscriber→projection-api path and wire both into the MkDocs nav. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1.6 KiB
1.6 KiB
Demo script
A running log of demoable outcomes, one section per slice. Each entry is a short,
copy-pasteable walkthrough against a local make up stack.
S-06 — Event Subscriber + read projection
Outcome: a zaak created in OpenZaak flows through NRC to the Event Subscriber, which projects it into a rebuildable read projection the projection-api serves.
The path: OpenZaak → (notification) NRC → (abonnement callback) Event Subscriber →
register_projection → projection-api GET /register.
# 1. Bring the full stack up (seeds config, builds our services, waits for health).
make up
# 2. Register the Event Subscriber's abonnement and create a zaak, then read it back.
# (The verify-projection check does exactly this end-to-end and asserts the result.)
make verify-projection # → "OK — projection-api serves zaak <uuid> with status INGEDIEND"
# 3. Observe the projection directly via the read API (host port 8120).
curl -fsS http://localhost:8120/register | jq
# → [ { "id": "<zaak-uuid>", "status": "INGEDIEND", "bsn": null, "naamPlaceholder": null } ]
# 4. Idempotency + rebuild: replays don't duplicate; a rebuild repopulates from the
# notification log (no OpenZaak access needed — ADR-0008).
curl -fsS -X POST http://localhost:8110/admin/rebuild # Event Subscriber, host port 8110
curl -fsS http://localhost:8120/register | jq 'length' # → unchanged
bsn/naam_placeholderare deferred (ADR-0008) — the notification doesn't carry them and the subscriber may not read OpenZaak directly (§8.1). They surface in a later slice.