83 lines
2.1 KiB
Markdown
83 lines
2.1 KiB
Markdown
---
|
|
name: "Adr 0008 Contract Enforcment With Tests"
|
|
description: "Contract testing to enforce event and replay invariants"
|
|
depth: 2
|
|
links: ["../index.md", "./adr-0006-event-store-append-only.md", "./adr-0007-projection-replay.md"]
|
|
---
|
|
|
|
# ADR-0009: Contract Testing Enforcement of Event & Replay Invariants
|
|
|
|
**status:** accepted
|
|
**date:** 08.05.2026
|
|
**deciders:** Kami
|
|
|
|
---
|
|
|
|
## context
|
|
|
|
System correctness depends not only on design-time invariants (ADR-0007, ADR-0008) but also on continuous enforcement across implementations.
|
|
|
|
Multiple EventStore and Replay implementations exist (in-memory, sqlite, future persistence layers). Without shared contract tests, invariants may diverge silently.
|
|
|
|
This ADR defines the role of contract tests as enforcement layer for system invariants.
|
|
|
|
---
|
|
|
|
## content
|
|
|
|
### 1. contract-first enforcement model
|
|
|
|
* all EventStore implementations MUST satisfy shared contract tests
|
|
* all replay implementations MUST satisfy shared replay contracts
|
|
|
|
### 2. EventStore contract requirements
|
|
|
|
Contract tests MUST enforce:
|
|
|
|
* append-only behavior
|
|
* idempotency of event_id
|
|
* strict ordering per session
|
|
* deterministic read consistency
|
|
* correct sequence continuity
|
|
|
|
### 3. Replay contract requirements
|
|
|
|
Contract tests MUST enforce:
|
|
|
|
* deterministic reconstruction of state
|
|
* identical results across repeated replay executions
|
|
* correctness over full event streams
|
|
* correctness over partial event streams (cursor-based replay)
|
|
|
|
### 4. implementation independence
|
|
|
|
* contract tests MUST NOT depend on specific implementation details
|
|
* tests operate only through interfaces (EventStore, EventReplayer, Projection)
|
|
|
|
### 5. cross-backend equivalence
|
|
|
|
* in-memory and persistent stores MUST produce identical replay results for identical inputs
|
|
|
|
---
|
|
|
|
## consequences
|
|
|
|
**positive:**
|
|
|
|
* prevents divergence between implementations
|
|
* guarantees correctness across persistence backends
|
|
* enforces architectural invariants at CI level
|
|
* makes replay correctness regression-resistant
|
|
|
|
**negative:**
|
|
|
|
* increases test suite complexity
|
|
* requires careful abstraction of test fixtures
|
|
* slower feedback cycles for persistence changes
|
|
|
|
---
|
|
|
|
## status
|
|
|
|
accepted
|