Countering vague client requirements with the Sitecore Rules Engine

This blog post is less about technical know-how and code samples and more about how you can leverage dynamic content (in occasionally unexpected circumstances) to guard against loose business requirements. I'm thinking about the kind of situations where you may be asked to implement a feature depicted by a design agency, where all kinds of rules and scenarios driven by domain/application data are implied, but perhaps not explicitly specified.

You could spend days drawing up diagrams and documents to try and capture the implicit behaviour in order to ascertain whether the client has the same interpretation that you do, but you know that the amount of communication travelling back-and-forth is going to delay the start of the implementation (not to mention that this process tends to be rather painful!) Often the client is disinterested in getting down to such a low level of detail whilst they are busy with other work - preferring to delay the "moment of truth" until they actually have to create the content "for real". This leads to the predictable cycles of bug-fixing and never-ending delivery of some ostensibly simple functionality!

A pragmatic alternative is to take your best guess, but work the logic in question into the application using dynamically editable rules (rather than hard-coding such logic) - in the Sitecore CMS this generally means using the Rules Engine. In some ways this forces part of the burden of fathoming out the correct behaviour back to the client - but in the long term they will benefit from being able to quickly tweak the rules rather than having to fork out more cash to pay for extra development work to remedy any problems. As a side effect, this approach also makes the rules in question more explicit and visible, rather than hidden away (although some clients may prefer that complex logic happens "by magic"!)

Anyone who is familiar with Sitecore will need no introduction to the Rules Engine - essentially, a combination of out-of-the-box and custom "Conditions" allows boolean logic to be dynamically composed via a dedicated field type which you can add to any template. "Actions" can be triggered as the chains of conditions are evaluated - again, it's easy to implement your own action (or use an one provided by Sitecore.) In the scenario below, I ran the rules in this field via some code which rendered an MVC view, opting to execute the action of the first-matching rule - you can alternatively execute *all* matching actions if that better fits your use case:

Rules fieldRules field

Obviously replacing hard-coded business rules with ones which are usefully editable/configurable relies on you being able to identity and code-up a meaningful set of "core" conditions which can be combined to create likely scenarios - hopefully you can see how this would be the case with the example above.

Another caveat - at the time of writing, I found that Sitecore 8.1 Update 2 seemed to have an issue with its rule "cache" which means that you might have issues with rule fields which vary between language versions of the item; I'll post an update when I get any more detail from Sitecore Support.

Even if you don't need or want the power of dynamic rules for your feature, you can still benefit from the approach of "rules" - consider using the specification design pattern to make domain or application logic explicit. This is encouraged by the Domain-driven_design approach, and ensures that your code is maintainable by separating the component rules into individual classes which can be composed into chains of logic. Among the many benefits of this approach are that it is easy to transplant this code to fit Sitecore's rule engine "Condition" and "Action" paradigm at a later date.

 


By James at 31 Jul 2016, 21:07 PM


Comments

Post a comment