An action-oriented answer might to the following.  The enforcement action implied by this rule is to check the salesperson's credentials.  The context for such a check might be just prior to the close of each sale, or perhaps upon an annual review of the salesperson's performance.

The business rule approach offers a distinctly different approach -- one based on events rather than actions.  Logically (meaning based on the business logic), there are precise changes-in-state (i.e., events) where the sample rule needs to be tested, as follows.  By the way, these same three rule-test events could be produced by dozens of different processes -- but the rule applies to all of them equally.

1. When a salesperson is indicated as selling a product.
2. When a salesperson ceases to present a manufacturer.
3. When a manufacturer ceases to produce a product.

Aside:  Note that there is more than one test-rule event (actually three) where this rule needs to be evaluated.  In general, analysis of any rule -- even very simple ones -- reveals at least two such test-rule events.

The business rule approach features an architecture with (at least) three primitives:  action (process), event, and rule.  These three primitives are mapped to each other as follows:  action (process) -- event -- rule.  This approach permits:  (1) unifying any given rule across all such processes, (2) ensuring that the rule is enforced consistently across all the processes, and (3) simplifying the processes themselves.

Consider another rule, this time an inference rule:  It-is-raining implies sidewalks-are-wet.  This rule actually provides two pieces of logic, as follows:

• If a fact is asserted that it is raining, then the fact that the sidewalks are wet can be automatically asserted.
• If sidewalks are known to be not wet, then it can be deduced that it isn't raining.

Again, this rule clearly illustrates the general case that there are always two or more rule-test events relevant to the evaluation of any rule.  The rule-test events relevant to this particular rule are:

1. When raining is indicated.
2. When sidewalks are not wet is indicated.

Here then is the big idea of the business rule approach.  Given a rule and the rule-test event(s) relevant to that rule , the enforcement action(s) for the rule can be assumed -- that is, left to a rule engine.

What does this say about approaches that essentially view rules as preconditions and/or post-conditions (to actions)?  The business rule approach shows it to be deeply flawed.  Business logic parsed that way can never lead to business logic managed by the business side.

Achieving the business capabilities demanded today (e.g., mass-customization, real-time compliance, near-zero latency, etc.) requires that business logic be directly validated and altered by business-side workers as an on-going business activity.  If action-oriented approaches were capable of producing such support, they already would have already done so.  The problem is with the paradigm itself.  Time for a seismic shift in how business logic is conceived and deployed!

# # #