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

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

New Issue
Closed
opened 2026-07-17 09:49:47 +00:00 by not · 1 comment
not commented 2026-07-17 09:49:47 +00:00
Contributor
Copy Link
Copy Source

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.

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:domainarea:workflowtype:adr-proposal labels 2026-07-17 09:49:47 +00:00
not commented 2026-07-20 07:28:05 +00:00
Author
Contributor
Copy Link
Copy Source

Resolved: ADR-0016 landed in PR #101 (S-13, merged). The decision recorded there is a DMN service task (flowable:type="dmn") rather than a businessRuleTask — the latter binds Flowable's legacy Drools/KIE impl that flowable-rest does not bundle. Closing.

Resolved: ADR-0016 landed in PR #101 (S-13, merged). The decision recorded there is a DMN service task (`flowable:type="dmn"`) rather than a `businessRuleTask` — the latter binds Flowable's legacy Drools/KIE impl that flowable-rest does not bundle. Closing.
not closed this issue 2026-07-20 07:28:06 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
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 labels area:domain area:workflow type:adr-proposal
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
eho (Edwin van den Houdt)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: eho/register-referentie#100