Business Rules, Decision Management and DMN
Scope
Separating decision logic from process flow, and the DMN constructs tested at fundamental level.
Core rules
- A business rule governs or guides behaviour: derivations (how a fact is computed), constraints (structural and operative) and action assertions. Rules belong in a managed rule catalogue rather than scattered through process flow.
- DMN separates decision logic from process logic. A decision requirements graph holds decisions, input data, knowledge sources and business knowledge models; the DRD is its diagram.
- Decision tables use input entries, output entries and a hit policy: U (unique), A (any), P (priority), F (first), C (collect with aggregation), O (output order). The default is U, which requires complete and non-overlapping rules.
- BPMN invokes decisions through a business rule task referencing a decision or decision service. FEEL is the standard expression language.
Worked example
A discount decision takes customer tier and order value: gold with value >= 1000 gives 15%; gold otherwise 10%; silver with value >= 1000 gives 8%; otherwise 0%. With hit policy U the analyst must show no two rules can fire together and every combination is covered, and the final otherwise rule guarantees completeness. Reasoning: U forces completeness and consistency checks, whereas F would silently hide overlaps and evaluation order.
Traps that cost marks
Leaving overlapping rules under hit policy U. Confusing the DRG (requirements structure) with the decision logic itself. Encoding rules in BPMN gateway conditions and then duplicating them in a rule engine, which guarantees drift.