Different kind of rules are used within an application. Business rules do have high business value. Different kinds of business rules exists in every layer within the clean architecture.



Example

Input validation

(Interface Layer)

  • Format validation (e.g. correct phone number, IBAN, postcode)
  • Type validation (e.g. only string is allowed)
  • Input required
  • Value validation (e.g. age >= 0)
  • Can we process this value? (e.g. amount > 0)
  • Is the value plausible? (e.g. a non-blocking validation rule, are you sure you want to apply for a 10 million Euro mortgage?)

Authorization/authenticatie rules

(Application Layer)

  • Can this user (role) see/modify this?
  • Can they overrule these warnings?

Process rules

(Application Layer and Domain Layer)

  • What is the next step?
  • Which activity is not allowed?

Policy, Deduction, Integrity, Calculation rules

(Domain Layer)

  • Are the various choices compatible?
  • Is this application acceptable?
  • Calculation
  • Decision based on policy rule

Business rules that might result in a negative decision (e.g. rejection of a credit application or subsidy) can be further characterized in different categories. For example, some applications distinguish between 'red' and 'orange', analogous to traffic lights. In accordance with e.g. GDPR art 22, such rules are open to review (and may be overruled) by case handlers. This review takes place without respect to the severity of the rule, as any rule might be broken in previously unforeseen circumstances. In that sense, every policy rule is ultimately a 'soft rule'. However, a useful distinction might be between rules that are open to human interpretation in every instance (e.g. open standards) versus rules for which there is no standing policy, necessitating a case-by-case approval/appeal process involving senior management.