When the applications business logic is not placed in a service layer then I would expect that it would be kept as visible and above water as you could make it. The idea being to facilitate maintenance and future development within/upon the process flow. I was wrong. I won't get into the long story about how we got to the point that we can rework this process flow, it is not very interesting and I imagine it is par for the course in most large software development organizations.
All in all, it has provided a very interesting first step in my current project to start working on this problem. I am currently migrating as much logic possible from the transitions back into the process steps or even creating new process steps to bring this functionality into the light. Visibility is the key here. My plans:
- Business logic is being encapsulated into services and pushed down into the SOA layer.
- Transitional actions are being brought up into process steps
- Core process steps are being black-boxed so that you can fill them with any eventual project specific sub-flow definitions as needed.
- Migrating almost all process nodes to state nodes to facilitate a proxy between the process instance node and the service layer (calls)
- Looking to add a custom jBPM class loader with maven like functionality to facilitate multiple projects running with different service versions (why we need this is an infrastructural problem)