Composing Workflows

In this module, we return to the concept of Rules as the building blocks for the Rulesets.  We’ll also cover some guidelines for designing Rules.

You are shown two different Lego configurations below, an: Angel (Left) and Poseidon (Right).   

Take a minute to inspect both configurations.  When you're ready....scroll down to reveal how this relates to designing rules.

In the left image, the little Lego wing piece has been composed together with other pieces to form an Angel.  In the right image, the same Lego piece is composed together with many other Lego pieces to form a Poseidon.

The visual analogy demonstrates how rules should be:

• Small, isolated single-purpose building blocks
• Reusable and composable with other rules to form more complex business logic
• Are the smallest building block for a task (ruleset) in a process

It also demonstrates how rulesets:

• Are composed of one to many building blocks
• May reuse rules from other rulesets one or more times
• Combine to perform a specific purpose or task within a process

Let’s dig a little deeper...

In the case of the Angel the piece portrays an angel wing, while in the case of the Poseidon the piece is composed with other instances and forms a mustache, beard, and eyebrows.  This is what rules are in the workflow framework — they can be composed together with other rules in a ruleset to form a completely unique outcome. 

Example: One ruleset may perform a certain task, while another ruleset composed of the same rule along with other rules performs a completely different task.

Below is an example of a Ruleset (Ruleset A) showing 4 Rules (rules 1 to 4) configured within it.  It illustrates the key concepts of rules execution, specifically:

• Every Rule in the Ruleset is executed in sequence.
• A Rule may or may not produce an outcome - i.e. it is conditional.

Multiple instances of a Rule are a design intention.

Each Ruleset executes in sequence for the given context or event.

Recommended practice regarding the naming convention for Rulesets

Each Ruleset should only have a single purpose, and a Ruleset that changes the state of an entity should be clearly named to reflect that purpose. 

This is done so that a Workflow is easy to read and thus becomes easier to support.

The diagram on the right shows an example, as well as a non-example of this recommendation.

Key Takeaways and Best Practices

A Rule consists of two components:

• The Rule Condition
• The Outcome (Action)

Rules are meant to be:

• Designed for a single purpose — they should do only one thing and produce only one action (if the Rule Condition is met).
• Simple, isolated and reusable — only use a few lines of code.  The key is not to lock away logic into the code.  This idea aligns with a core value proposition we're trying to promote of flexibility and readability.   
• Reused - try to reuse as many of the Rules as possible.  It might just be that their parameters are configured slightly differently or they may be in a slightly different sequence — that's our intention.

Note: Rules do not have to always produce an Action.

When naming and defining Rulesets:

• Aim to provide meaningful, descriptive names so that the workflow becomes self-describing and intuitive.  
• Try to align the name according to the piece of logic or function the Ruleset is performing within the workflow.  This makes it easier for other people to review a workflow and understand its intention.

Benefits of applying rule best practices:

• If there's a change in business requirements, it's easier to go in and make one, quick change.
• Having single-purpose, isolated Rules simplifies the troubleshooting process, making it easier and faster to navigate the workflow and pinpoint and resolve issues.

Rulesets should be of a single purpose, such as to:

• Perform a single function (E.g: CancelOrder) OR
• Perform a logical gate for directing execution flow by using If/Else logic OR
• Perform a State Management (E.g: SetAwaitingPayment) OR
• Perform another purpose, such as notifying other orchestration contexts or other domains. (E.g.,  If an order comes in, notify the Inventory Catalog to reserve the product at that particular location — You will learn more about logical gates & state Management in the next lesson.