Documentation for a newer release is available. View Latest

How Do I Use Code Generated by the DSL?

This page explains how to get started with the code generated by the DSL in a flo-lang project. It describes all the different interfaces that are generated and reviews the central domain class that is used to interact with the domain itself.

What Code is Generated?

There are a number of classes generated by the DSL that facilitate interaction between the domain model and the application code. In typical use cases, the most important classes to be be aware of are:

  • The '<ABC>ModelDomain' class, which has the following naming structure: '<ABC>Domain', where <ABC> is the DSL model name. This class offers access to all the features of the domain, and must be constructed as part of the application bootstrapping process.

  • The 'ModelOperations' class, which has the following naming structure: '<ABC>ModelOperations', where <ABC> is the DSL model name. This class provides useful information about the domain and serves as an entry point for other IPF components to interact with it. Accordingly, this component should be registered in the Spring context.

  • Ports - for each DSL component (External Domain request, Domain Function, Decision etc) there will be a single matching port made available. Clients are expected to provide adapter implementations of these interfaces, which can then be registered using the adapter methods provided by the domain.

When looking at the model domain class, it will provide the mechanism to register an adapter with the domain.

In order for the domain to initialise correctly, all of the adapters defined in the flow must be provided to it on startup. Therefore, a validation check is performed by the domain during startup, and the application will fail to start if it detects that any adapters are missing.

Where is the Generated Code?

All of the code generated by the DSL is located within the target folder of the 'domain' module in your solution. Note how each model resides in its own separate package (e.g. a_simple_decision), as shown in the screenshot below:

work generation 1