docs: add WP-68, aggregate invariants + status modelling

Architecture review found the context boundaries, FP/TEA idioms and read/write separation sound, and rejected explicit CQRS as the fix for anything found. It located four real defects clustered in one place: the backend's aggregate roots don't guard their own invariants, and the aanvraag status lifecycle is a computed string living in the contracts layer instead of the domain. Full Decisions block pre-made so implementation can proceed without re-litigating scope. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-05 15:20:55 +02:00
parent 6cfd70eeeb
commit 6a4a0ad435
2 changed files with 285 additions and 0 deletions
@@ -118,6 +118,7 @@ for its existing violations, so every WP ends green.
 | [WP-65](WP-65-behandelportal-beoordeling.md)           | Behandelportal: zaak detail + beoordeling (decision) screen                        | 11 · Behandelportal         | done   |
 | [WP-66](WP-66-behandelportal-openzaak-write.md)        | Wire the decision into OpenZaak                                                    | 11 · Behandelportal         | done   |
 | [WP-67](WP-67-monorepo-behandelportal.md)              | Merge behandelportal into this repo as a monorepo                                  | 11 · Behandelportal         | done   |
+| [WP-68](WP-68-ddd-aggregate-hardening.md)              | Aggregate invariants + status modelling (architecture review)                      | 12 · DDD hardening          | todo   |

 Sequencing dependencies (stated in the WPs too): 01 before 10–15 (axe covers story churn);
 03/04 before 05–09 (boundaries stop new violations during refactors); 06 before 07 (typed