An understandable misunderstanding
The interactor executes a usecase dependent on the message.
You actually got the words right, but I'm seeing from your graphic that this can be interpreted in 2 different ways. You interpreted it as
"The interactor chooses a usecase dependent on the message."
But it's rather
"The interactor executes a use case with the data from the message."
In your defense, the terminology can be confusing and sometimes different names are used to describe the same things.
An interactor represents a use case, not a list of use cases
In a way, an "Interactor" is a "use case". This is way easier to explain with an example though.
Imagine a web shop. In a business sense, you have the use case "add a product to the basket." The "recipe" for what happens in that use case is written down in a
Now your user enters a number and presses a button in the outer "frameworks and drivers" layer. That layer passes the raw information on to your controller.
The controller puts the product ID and the number for the amount into a
AddProductToBasketRequest - that's your "message". Then it calls
Dependent on the message
Now, "executes a usecase dependent on the message" just means that what the interactor does has to do with the input it gets.
For example, how many products to add is dependent on the data in the message.
Maybe if the customer adds 10, they get 5% off.
Maybe the product ID does not exist, so it never actually changes the basket and returns an
AddProductToBasketResult with an error flag.
No list of interactors
Your interactors "stand alone", they don't have to be put into a list of use cases.
An interactor coordinates "workers" in the "interface adapters" layer, so that a use case (the business term) happens.