Reuse

In generation we discussed the different elements that are created and that how these are used at the model level. Now, in this section, we introduce the concept of reuse.

Reuse occurs when you have a common piece of DSL code that can then be used across multiple different IPF flow projects. For example, consider a sanctions system: many different flows might want to interact with a sanctions system, although these flows themselves may have no knowledge of or relationship to each other, and may be deployed separately.

One option here would be to create a different DSL component representing a sanctions system in each model and then provide the many separate implementations of this. Whilst this is simple to do, it would mean maintaining multiple copies of essentially the same capability and the managing the issues that this is likely to introduce. This is where reuse comes in: the ability for one model to call a function in another model.

In essence it’s simple. You can import a dependency from one model into another, and then reference the components of the shared module from the core one. A typical pattern for this might be:

In this scenario, we’d add model A as a dependency to both model B and model C, allowing both B and C to use the (same) components defined in model A. At a generation level, each of models A, B and C will be separate and each will have it’s own ModelDomain that needs to be implemented, meaning that all the logic for the implementation of the shared function is kept separate and isolated. The models then know how to communicate with each other, so you only need to implement the sanctions logic in Model A once, and then it will be available to both models B & C simply by importing a dependency.

Let’s think about how this might look, from an overall perspective:

Here we can see how we might create our custom DSL components and then import in the reusable components such as sanctions. The reusable model is implemented in exactly the same way as the custom ones.