Shared architecture for multiple workflows


#1

Hi all,

I am wondering what your experience or thoughts are regarding the general architecture of a multiple workflows. We are implementing like 10-20 different workflows for our company. All of them share some common things, e.g. data from the internal system must be retrieved with the start in every single process. There are further service tasks that are always the same in every process (e.g. saving data back to the system). We handled it the way that we made a library that is included as a maven dependency (scope: provided) and includes the common logic for all processes.

However, I see the general problem what happens once we change the common library. In case we work with different versions, all processes must be re-complied and deployed again (will give a headache with running processes). Therefore, the only option would be to use only one SNAPSHOT version that can be overwritten in the lib-folder and will therefore then be used by every process without re-deployment. As a downside, no versioning will be possible any longer.

For some servicetasks I could even live with the fact, that re-deployment is necessary as they will change very seldom. But on the other hand, we work with DTO-Objects that are shared between several processes. Lets image a object that represents a document and is shared between several processes (one where the document is created, one where it is approved and so on). So where to put the DTO object? Changes to the DTO object occur quite often, as sometimes an additional variable must be added. If it is in the shared library then this will cause a lot of problems. If I include in in every process again we will have to cope with redundancy and problems when changing the variables in the object as it must be done in every process, hence the need to deploy them all again.

What I already thought about is to put some of the shared logic in a rest api that can then be versionated on its own and there will be no need for constant redeployment. But this will not solve problems like the DTO-issues.

Would be great to hear how others approach these problems.


#2

Hi @Tristan1,

it’s a common way to decouple the shared logic and provide separated services which can be called by the different processes (microservice-like).
In order to reduce the problems with the shared DTOs, you can use primitive or JSON variables and access them in a backwards-compatible way (i.e. use default values for missing properties). Protobuf or another higher level format is also possible. So you don’t need to redeploy all process applications at once.

Best regards,
Philipp