How to account for FQCN of workflows/activities change?

[lezhnev74]

In a big project FQCNs will have to evolve (as due to refactoring, domain splitting, etc). And as I see it stores direct class names in the db. I wonder if that is doable for me to extend or kind of the built-in behaviour with no options?

So far I am used to this strategy:

• each FQCN that goes beyound runtime boundaries is mapped to a storage key
• when it goes back, the code selects the appropriate FQCN by the ky and reconstructs the object.
• that requires maintaining a map of fqcn<->storageKey pair.

[rmcdaniel]

Currently the workflow/activity FQCN is used as the persisted identifier. So far the expectation has been that old classes remain resolvable (e.g. via thin compatibility wrappers) when refactoring.

I’ll take a look at what it would take to introduce a backward-compatible alias mechanism for workflows and activities, without breaking existing persisted executions.