Business Rule Discovery
Definition
Find the rules that decide what is allowed, required, calculated, blocked, or changed. Business rules should be owned explicitly so they do not leak across UI, routes, data access, and tests.
Questions To Ask
- What must always be true?
- What is allowed, forbidden, required, optional, or calculated?
- Who can make this decision?
- What changes when user type, time, status, amount, or location changes?
- Which rules are legal, policy, workflow, or product choices?
Existing Project Comparison
- Search validation, conditionals, database constraints, tests, comments, and UI copy.
- Compare duplicate rules across layers.
- Identify rule owners and places where rules are only implied.
- Flag rules that are spread across modules and increase change amplification.
Suggestive Plan
- Extract candidate rules from each feature.
- Mark invariant, policy, calculation, permission, or lifecycle rule.
- Assign an owner module.
- Add examples and counterexamples.
- Record unknown rules as questions.
Example
"Appointment can be cancelled by a patient until 24 hours before clinic-local start time" is a business rule. The owner is scheduling, not the UI.
Vocabulary
- Business rule: domain decision that controls behavior.
- Invariant: rule that must always remain true.
- Policy: organizational decision that may change.
- Rule owner: module responsible for enforcing and explaining a rule.
- Leakage: the same rule duplicated in multiple places.
Expected Outcome
Produce a rule catalog with rule text, type, owner, examples, enforcement point, tests needed, and open questions.
1---2name: business-rule-discovery3description: Discover business rules, invariants, policies, limits, and decisions hidden inside outcomes, journeys, actions, or existing code. Use when feature maps need domain rules before implementation or when rules appear duplicated across a project.4---56# Business Rule Discovery78## Definition910Find the rules that decide what is allowed, required, calculated, blocked, or changed. Business rules should be owned explicitly so they do not leak across UI, routes, data access, and tests.1112## Questions To Ask1314- What must always be true?15- What is allowed, forbidden, required, optional, or calculated?16- Who can make this decision?17- What changes when user type, time, status, amount, or location changes?18- Which rules are legal, policy, workflow, or product choices?1920## Existing Project Comparison2122- Search validation, conditionals, database constraints, tests, comments, and UI copy.23- Compare duplicate rules across layers.24- Identify rule owners and places where rules are only implied.25- Flag rules that are spread across modules and increase change amplification.2627## Suggestive Plan28291. Extract candidate rules from each feature.302. Mark invariant, policy, calculation, permission, or lifecycle rule.313. Assign an owner module.324. Add examples and counterexamples.335. Record unknown rules as questions.3435## Example3637"Appointment can be cancelled by a patient until 24 hours before clinic-local start time" is a business rule. The owner is scheduling, not the UI.3839## Vocabulary4041- Business rule: domain decision that controls behavior.42- Invariant: rule that must always remain true.43- Policy: organizational decision that may change.44- Rule owner: module responsible for enforcing and explaining a rule.45- Leakage: the same rule duplicated in multiple places.4647## Expected Outcome4849Produce a rule catalog with rule text, type, owner, examples, enforcement point, tests needed, and open questions.
harsh817