ADR: diploma-eligibility DMN evaluated as a BPMN businessRuleTask (S-13) #100

New Issue

not · 2026-07-17T09:49:47Z

not commented

2026-07-17 09:49:47 +00:00

Recorded ahead of S-13 (#14) per CLAUDE.md §14 (non-obvious decision + touches the workflow boundary). ADR file will land as docs/architecture/adr-0016-*.md in the implementing PR.

Decision to be made: Where is the diploma-eligibility DMN evaluated, and how does it drive the foreign→CBGV-advies routing?

Context / forces: The Flowable REST app bundles a DMN engine, and the same repository/deployments endpoint that deploys registratie.bpmn can deploy a .dmn. §8.2 makes the Workflow Client the only code that talks to Flowable; the PRD frames the workflow as "BPMN + DMN governing the registration workflow" (orchestration via Flowable as a peer module). The registration must carry a diploma origin (domestic/foreign; eIDAS ⇒ foreign) as the decision input.

Options considered:

DMN as a BPMN businessRuleTask (chosen). Flowable evaluates the deployed diploma-eligibility DMN inline as a workflow step; an exclusive gateway routes foreign diplomas through a new CBGVAdvies user task before Beoordelen, domestic straight to Beoordelen. Decision logic lives in the engine.
Domain evaluates the DMN via the Workflow Client (the issue's literal wording). The Domain Service calls Flowable's DMN REST API and feeds the result back as a process variable.

Proposed option + why: Option 1. It keeps the decision a first-class workflow concern (matching the PRD's BPMN+DMN framing), avoids coupling the domain to Flowable for a decision, and keeps §8.2 clean — the process the Workflow Client already started runs the DMN itself. The domain's only new responsibility is carrying the diploma origin and passing it as a start variable.

Consequences: The registratie process gains a businessRuleTask + exclusive gateway + CBGVAdvies user task; the DMN is version-controlled in workflows/ and deployed like the BPMN. The DMN is validated live (evaluated in isolation via the DMN API + the foreign path exercised through the process), consistent with ADR-0009/0014/0015. Deviates from #14's literal "evaluated by the Domain Service via Workflow Client" wording — noted on the issue.

Coupling rules touched (CLAUDE.md §8): §8.2 — upheld. The Workflow Client remains the only code talking to Flowable; the DMN runs inside the engine as part of the process, not via a domain round-trip.

Recorded ahead of S-13 (#14) per CLAUDE.md §14 (non-obvious decision + touches the workflow boundary). ADR file will land as `docs/architecture/adr-0016-*.md` in the implementing PR. **Decision to be made:** Where is the diploma-eligibility DMN evaluated, and how does it drive the foreign→CBGV-advies routing? **Context / forces:** The Flowable REST app bundles a DMN engine, and the same `repository/deployments` endpoint that deploys `registratie.bpmn` can deploy a `.dmn`. §8.2 makes the Workflow Client the only code that talks to Flowable; the PRD frames the workflow as "BPMN + DMN governing the registration workflow" (orchestration via Flowable as a peer module). The registration must carry a diploma origin (domestic/foreign; eIDAS ⇒ foreign) as the decision input. **Options considered:** 1. **DMN as a BPMN `businessRuleTask` (chosen).** Flowable evaluates the deployed `diploma-eligibility` DMN inline as a workflow step; an exclusive gateway routes foreign diplomas through a new `CBGVAdvies` user task before `Beoordelen`, domestic straight to `Beoordelen`. Decision logic lives in the engine. 2. **Domain evaluates the DMN via the Workflow Client** (the issue's literal wording). The Domain Service calls Flowable's DMN REST API and feeds the result back as a process variable. **Proposed option + why:** Option 1. It keeps the decision a first-class workflow concern (matching the PRD's BPMN+DMN framing), avoids coupling the domain to Flowable for a decision, and keeps §8.2 clean — the process the Workflow Client already started runs the DMN itself. The domain's only new responsibility is carrying the diploma origin and passing it as a start variable. **Consequences:** The registratie process gains a `businessRuleTask` + exclusive gateway + `CBGVAdvies` user task; the DMN is version-controlled in `workflows/` and deployed like the BPMN. The DMN is validated live (evaluated in isolation via the DMN API + the foreign path exercised through the process), consistent with ADR-0009/0014/0015. Deviates from #14's literal "evaluated by the Domain Service via Workflow Client" wording — noted on the issue. **Coupling rules touched (CLAUDE.md §8):** §8.2 — upheld. The Workflow Client remains the only code talking to Flowable; the DMN runs inside the engine as part of the process, not via a domain round-trip.

not added the area:domain area:workflow type:adr-proposal labels 2026-07-17 09:49:47 +00:00

not referenced this issue

2026-07-17 09:49:48 +00:00

S-13 · DMN decision: diploma eligibility (Flow 4) #14

not referenced this issue from a commit

2026-07-17 10:06:30 +00:00

test(workflow): start carries diploma origin as a process variable (S-13, refs #14)

not referenced this issue from a commit

2026-07-17 10:06:30 +00:00

docs(workflow): ADR-0016 + demo note for diploma-eligibility DMN (S-13, refs #14)

not referenced this issue

2026-07-17 10:06:52 +00:00