Current implementations of N2B and M2B support only a single hardcoded strategy of specifying the concrete bean type, which is based on the class property.

The linked issue from the UI raises the requirement for other "fuzzy" strategies of guessing the exact bean type (e.g. as the linked ticket suggests - the "fieldType" property could be used instead of the "class" for the case of the FieldDefinition-related objects).

In order to allow the developers (at least the Magnolia team) to create and use custom strategies without the need to change the transformers' code, the type "elaboration" has to be generalised into an API. Such API would manage and orchestrate different resolvers and automatically delegate resolution to the appropriate ones. In this case the existing "class"-property based resolution becomes one of the implementations of such strategy.