Intent

Use a Shared Part as a function-like component: pass inputs via variables, run logic inside the Shared Part, and read outputs from variables assigned by the Shared Part.

This promotes reuse, enables more generic solutions, and reduces repeated logic across templates.

Problem

The same validation or calculation is often needed in multiple templates. Repeating the same logic increases the chance of inconsistencies and bugs.

Duplicating code violates the DRY principle, which makes maintenance and debugging harder.

Solution

Create a Shared Part that:

• reads input variables set by the calling template
• performs the required logic
• exposes output variables back to the template

Structure

Examples / Applicability

Check validity of a company number

• The shared part takes the company number as the client has entered it in the template.
• It makes sure that it has the correct format to be checked.
• Performs logic to check if the number is valid
• Returns the result of the check

Calculate a flat rate amount

• An amount is assigned in the template
• The shared part holds information regarding to the calculation that needs to happen
• Calculation takes place in the shared part
• Result of the calculation is used further in the template

How to implement

• The Shared Part should have a single responsibility and contain one well-defined function (Single Responsibility Principle).
  • Typically: one check or one calculation.
• The Shared Part should only depend on the variables it needs to perform the task (Interface Segregation Principle).
• The function should have a clear name that suggests its purpose.
• If possible, the function should not be workflow-specific

Pros and cons

Pros

• Less duplicate code
• Improved maintainability since the logic only needs to be updated in one place
• Better readability because you only need to make sure you understand the function one time
• Faster development: no need to write code more than once when it is not needed

Cons

• Risk of taking up too much logic in the shared part
• Logic can be abstract and as a result harder to follow
• Not enough abstraction can lead to not enough use-cases covered
• Faulty code in the function can cause errors in the larger codebase
• Lack of documentation will risk the function to not work properly