Files

T

ehoandClaude Sonnet 5 a6a1abbe9c feat: implement strangler-fig-demo Session 1 (backend + smoke script)

Builds the four-seam, three-write-path reference demo backend: case-framework
(seam D stand-in), legacy-backend/frontend (SQL Server, seams A/B/C targets),
and new-backend (Domain/Application/Infrastructure.*/Api implementing the
source resolver, take/release-ownership, write-through translator, and owned
assessment flow), wired together via docker-compose with a plain placeholder
frontend standing in for the Angular portal until Session 2.

All 11 Architecture.Tests pass and scripts/smoke.sh passes end-to-end against
a fresh `docker compose up`, covering acceptance criteria 1-3 and 7-22.

Fixes two real domain bugs found only once the stack ran for real: the BSN
eleven-proof checksum trivially passes all-zero digits, and the adoption
mapper silently treated a partial legacy address as absent instead of failing
loudly. Also fixes several environment-specific integration issues (rootless
Podman/SELinux bind-mount permissions, a buildah NuGet layer-caching bug,
SqlClient's invariant-globalization incompatibility, and an nginx path-prefix
mismatch for the legacy frontend).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-07-31 07:57:26 +02:00

2.5 KiB

Raw Blame History

ADR-001: A register decision takes effect independently of case closure

Status

Accepted.

Context

case-framework (seam D, a stand-in for a maintained vendor case-management framework) refuses POST /cases/{id}/closure-request with 409 Conflict while any task on the case is still open. That rule belongs to the framework and is not ours to change — it is a conformist integration by design (§6).

The new domain's own rule is different: once an assessment (approve/reject) is recorded on a RegistrationApplication, that decision is legally in effect immediately. It cannot wait for an administrative task (e.g. a filing or notification step) to be ticked off in a separate system.

These two rules can genuinely conflict: an assessment can be recorded while a case-framework task is still open, at which point the case cannot yet be closed.

Decision

Recording an assessment and requesting case closure are treated as two separate, non-transactional steps:

POST /api/worklist/owned/{id}/assessment records the decision on the aggregate and commits it. This always succeeds if the domain invariants are satisfied, regardless of case-framework's task state.
The handler then calls POST /cases/{id}/closure-request on seam D as a best-effort follow-up. A 409 here is an expected, non-exceptional outcome, not a failure: the assessment is not rolled back, and the response reports closurePending: true instead of an error.

The user-facing consequence: the outcome is decided immediately, with the UI showing Besluit vastgelegd. Administratieve afsluiting in afwachting. when closure is still pending. Administrative closure catches up whenever the remaining task is completed — a scenario this demo does not automate, since it is not a claim about the framework, only proof that it can lag safely.

Consequences

The domain layer's assessment-recording method must not be coupled to case-framework's closure semantics — it has none of that knowledge, by design (New.Domain/New.Application never reference the case-framework client, see Architecture.Tests rules 1 and 8).
A case can sit in "decided but not administratively closed" indefinitely. That is accepted, not a bug: it is the visible cost of a conformist integration whose task-completion timing this system does not control.
No compensating transaction exists for a closure-request failure, because there is nothing to compensate — the assessment was correct and complete on its own terms.

2.5 KiB Raw Blame History