7 Signs your Rules are doing too much

Introduction

Fluent OMX Rules are the building blocks for orchestrated logic. They are not intended to be large, monolithic functions but rather small composable building blocks for logic within a workflow.

So, how can you tell if your Rules are doing too much?

In this article, I discuss the 7 signs that your Rules are doing too much and offer suggestions for how to simplify and break them down into small composable building blocks.

#1 Complex and long Rule name and description

This could actually present in 2 different ways:

• The Rule name and description is long, and the description potentially uses multiple sentences to explain itself
• The Rule name is short but does not explicitly explain what the Rule does

Both of these are a signal the Rule is doing too much.

The Rule naming guidelines provide insight into how to name rules. The key points here are that the name should suitably describe what the Rule does and that it should be as concise as possible. If you can’t name your Rule within about 5 words or less, perhaps it is doing too much?

Similarly, if your Rule descriptions are long, complex, or require multiple sentences to explain, then the Rule is likely doing too much. The Rule description is supplementary to the Name and allows for the Rule parameters (or properties) to provide context for the specific instance use of the Rule in a workflow. If the job of the Rule cannot be concisely explained in a short sentence, then it is likely doing too much.

Identify each part of the long or complex description (for example, between commas, full stops, “ands” and “ors”, and see if perhaps each of those should be split into separate rules.

#2 Too many parameters (and "optional" parameters)

Rules that require more than 1 or 2 parameters are likely doing too much. 3 parameters is typically the max expected.

Look at the Rule code and try to identify each step or task the Rule is performing. You may realize you can break it into separate Rules, which would reduce the number of required parameters.

Additionally, parameters should always be required and not optional. If you’re using optional parameters, it might be a signal that not all code paths use the parameter, and therefore it should be a separate thing.

Optional parameters also make for a poor user experience for Rule configuration. Identify why the parameter is optional, and consider moving the logic that requires the parameter into a specific workflow branch to avoid unnecessary complexity on configuration of the primary Rule.

#3 Multiple event names

If your Rule takes in multiple event names, it is likely covering several logical gates internally. This is an anti-pattern. Move this logic to the workflow.

Implement logical gate Rulesets to control flow toward task Rulesets.

#4 Multiple different actions

Does your Rule mutate and send events? Ask yourself why. A Ruleset is the right construct to build logic that includes multiple actions, not rules. As soon as you have a new requirement that needs to be injected between the mutation and the sending of an event, you will need to change code. If they are built into a Ruleset, this can easily be done by slotting a new rule between the mutate Rule and the send event Rule.

Separate mutation rules from flow control rules.

#5 Arrow Code

Arrow Code is where you have too many nested if else and else if conditions. This creates higher cyclomatic complexity, making the code more error-prone.

Use guard statements, and exit early. Move logical gates to the workflow.

#6 Requires lots of logging

If the only way to understand what is going on in the rule is with many lines of logging, the rule is likely doing too much. Bear in mind that the Workflow Engine produces Orchestration Audit Events, which take a snapshot of the Entity state at the start of execution, and track each Ruleset, Rule, and Action performed within the execution. If this is not enough to understand what is happening, it is a strong signal that the Rule is doing too much.

Identify each step or task the Rule code is performing and break it into separate Rules.

#7 Lines of code

While it is not valid to put a strict limit on lines of code, this could be a signal that the rule is doing too much. Have you extracted a number of private methods? What are these methods doing? Should they, in fact, be rules themselves? Of course, this is not always the case, and often, this can signal the need for extracting common boilerplate code into utilities or services, which can be shared by a number of rules.

Nevertheless, if your Rule class code does exceed 50 lines (including imports, javadocs, and annotations), or require scrolling to see the whole code, it is worth reviewing whether it is doing too much.

Conclusion

As with most things life, there are shades of grey in the above. None of them are absolutes, however they are some key signals to consider to ensure your Rules are as small and composable as possible.

And remember, there are many reasons why your Rules should be small and composable.