Circumstancing seems like a very flexible way to handle exceptional business rules.
However, since the circumstanced rule is a copy of the base rule, there could be many common logics existing in both base and circumstanced rules, and if we have to modify those common logics, the more circumstanced rules could bring more maintenance overhead.
Another concern with circumstanced rule is the complexity of its rule resolution approach, which may cause more confusion than the clarity.
I would like to hear stories both happy and sad, from you who has the experience of using circumstanced rule in the real world projects, to get some ideas about the best practices for using circumstanced rule.
Message was edited by: Chunzhi Hong
Just wanted to pop-up this discussion up in the list.
***Moderator Edit: Vidyaranjan | Converted Question to Discussion***
I have recently been looking at decision table rules, and I see that in the "otherwise" clause at the end, there is an option to "call base rule". So, for decision tables, if you isolate only your circumstance details to the circumstanced rule and keep the common details in the base rule, you should be able to avoid duplicating details. /Eric
Can you assume that circumstancing is as-a-rule [if possible at all :) ] is preferred to creating a circumstanced as a seperate rule in a flow construction with a preceeding decision-shape ? I would expect that. But is that justified...