eho/register-referentie
1
0
Fork 0
Code Issues 16 Pull Requests 1 Actions Packages Projects Releases 1 Wiki Activity

feat(#13): S-12a — beoordeling decision model (domain) #82

Open
not wants to merge 7 commits from feat/13-behandel-decision-model into main
pull from: feat/13-behandel-decision-model
merge into: eho:main
Conversation 0 Commits 7 Files Changed 8 +450 -12
not commented 2026-07-14 15:26:36 +00:00
Contributor
Copy Link

What & why

First sub-slice of S-12 (#13) — the beoordeling decision model in the Domain Service. Foundation for the behandel-portal: it gives the domain a proper decision lifecycle before any UI/Flowable/BFF work.

  • Statuses: add InBehandeling and Afgewezen to RegistrationStatus.
  • Aggregate: TakeIntoBehandeling() (Ingediend → InBehandeling, idempotent, guards terminal states); generalise the behandelaar decision — Approve() (requires a zaak) and new Reject() both act on an Ingediend/InBehandeling registration → Ingeschreven/Afgewezen.
  • Use-case: BeoordeelRegistratie (goedkeuren sets the zaak's final status via the ACL §8.1 → Ingeschreven; afwijzen → Afgewezen, domain-only for now). Idempotent.
  • Endpoint: POST /registrations/{id}/decide ({ "besluit": "goedkeuren" | "afwijzen" }), superseding the temporary /approve (retired when the portal lands, S-12d).
  • BDD: EenRegistratieBeoordelen.feature — goedkeuren + afwijzen scenarios (feature-scoped bindings).

Scoped out to later S-12 sub-slices: Flowable user-task claim/complete + BPMN userTask (S-12b), BFF /behandel/* + medewerker authz (S-12c), the Angular behandel-portal + e2e (S-12d), and propagating a rejection to the zaak/projection via the ACL.

Definition of Done

  • Linked issue: #13 (umbrella; this PR refs, does not close)
  • Tests first; red → green per behaviour
  • Unit + acceptance green (make unit): domain 65, acceptance 9
  • Mutation ≥ break(90): domain 98.77%, no survivors in new code (the one unkilled mutant is the pre-existing FlowableWorkflowClient baseline)
  • CI green (pending)

Part of #13.

## What & why First sub-slice of **S-12 (#13)** — the **beoordeling decision model** in the Domain Service. Foundation for the behandel-portal: it gives the domain a proper decision lifecycle before any UI/Flowable/BFF work. - **Statuses:** add `InBehandeling` and `Afgewezen` to `RegistrationStatus`. - **Aggregate:** `TakeIntoBehandeling()` (`Ingediend → InBehandeling`, idempotent, guards terminal states); generalise the behandelaar decision — `Approve()` (requires a zaak) and new `Reject()` both act on an `Ingediend`/`InBehandeling` registration → `Ingeschreven`/`Afgewezen`. - **Use-case:** `BeoordeelRegistratie` (`goedkeuren` sets the zaak's final status via the ACL §8.1 → `Ingeschreven`; `afwijzen` → `Afgewezen`, domain-only for now). Idempotent. - **Endpoint:** `POST /registrations/{id}/decide` (`{ "besluit": "goedkeuren" | "afwijzen" }`), superseding the temporary `/approve` (retired when the portal lands, S-12d). - **BDD:** `EenRegistratieBeoordelen.feature` — goedkeuren + afwijzen scenarios (feature-scoped bindings). **Scoped out** to later S-12 sub-slices: Flowable user-task claim/complete + BPMN `userTask` (S-12b), BFF `/behandel/*` + medewerker authz (S-12c), the Angular behandel-portal + e2e (S-12d), and propagating a *rejection* to the zaak/projection via the ACL. ## Definition of Done - [x] Linked issue: #13 (umbrella; this PR `refs`, does not close) - [x] Tests first; red → green per behaviour - [x] Unit + acceptance green (`make unit`): domain 65, acceptance 9 - [x] Mutation ≥ break(90): domain 98.77%, no survivors in new code (the one unkilled mutant is the pre-existing `FlowableWorkflowClient` baseline) - [ ] CI green (pending) Part of #13.
not added 7 commits 2026-07-14 15:26:37 +00:00
test(domain): a behandelaar can take a registration into behandeling (refs #13) 23125ef492 
First step of S-12a (beoordeling decision model): an INGEDIEND registration moves
to IN_BEHANDELING when a behandelaar picks it up. Red — TakeIntoBehandeling() and
the InBehandeling status do not exist yet.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
feat(domain): take a registration into behandeling; generalise decisions (refs #13) 09000d8e64 
Adds InBehandeling + Afgewezen statuses and TakeIntoBehandeling(). Generalises the
behandelaar decision: Approve() (requires a zaak) and new Reject() both act on an
INGEDIEND or IN_BEHANDELING registration, moving it to Ingeschreven/Afgewezen.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
test(domain): lock beoordeling transitions — reject, idempotent re-take, guards (refs #13) 5c05879cde 
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
test(domain): beoordeling use-case — goedkeuren via ACL, afwijzen, idempotency (refs #13) 63699c3f55 
Red — the BeoordeelRegistratie use-case and BeoordelingsBesluit do not exist yet.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
feat(domain): implement the beoordeling use-case (goedkeuren/afwijzen) (refs #13) d700659957 
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
test(acceptance): beoordeling scenario — goedkeuren via ACL, afwijzen (refs #13) ddebfd371a 
BDD scenarios (Gherkin/Reqnroll) driving S-12's decide flow: a behandelaar takes an
INGEDIEND registration into behandeling and decides it goedkeuren (→ INGESCHREVEN,
zaak status via the ACL) or afwijzen (→ AFGEWEZEN, no ACL). Feature-scoped bindings
avoid clashing with the identically-phrased status step in RegistratieIndienen.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
feat(domain): expose POST /registrations/{id}/decide for the beoordeling (refs #13)
All checks were successful
CI / lint (pull_request) Successful in 1m20s
Details
CI / build (pull_request) Successful in 1m12s
Details
CI / unit (pull_request) Successful in 1m32s
Details
CI / frontend (pull_request) Successful in 2m47s
Details
CI / mutation (pull_request) Successful in 6m6s
Details
CI / verify-stack (pull_request) Successful in 7m45s
Details
7693a4a85a 
The behandel-portal's decision reaches the domain here (via the BFF, later slices):
goedkeuren/afwijzen, idempotent, superseding the temporary /approve endpoint.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
not added the type:slicearea:domain labels 2026-07-14 15:26:41 +00:00
All checks were successful
CI / lint (pull_request) Successful in 1m20s
Required
Details
CI / build (pull_request) Successful in 1m12s
Required
Details
CI / unit (pull_request) Successful in 1m32s
Required
Details
CI / frontend (pull_request) Successful in 2m47s
Details
CI / mutation (pull_request) Successful in 6m6s
Required
Details
CI / verify-stack (pull_request) Successful in 7m45s
Required
Details
This pull request can be merged automatically.
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin feat/13-behandel-decision-model:feat/13-behandel-decision-model
git checkout feat/13-behandel-decision-model
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
area:acl
area:bff
area:docs
area:domain
area:event-subscriber
area:infra
area:portal-behandel
area:portal-beheer
area:portal-openbaar
area:portal-self-service
area:projection
area:workflow
type:adr-proposal
type:bug
type:chore
type:slice
No Label area:domain type:slice
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
eho
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: eho/register-referentie#82
Delete Branch "feat/13-behandel-decision-model"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?