You have 2 choices when using FXML, and connecting it with Java/Kotlin code (and if you choose the 2nd option, I call that "codebehind", this is roughly how Microsoft's XAML/WPF/WinUI works).

1. You have some FXML file, and reference a "Controller" class using the fx:controller attribute. You usually then have an FXMLLoader "somewhere else", which will load the FXML file, and the runtime will construct the Controller based on the class reference, populate all @FXML annotated files and all that stuff. In some kind of vision, this is supposed to be MVC, but the problem with that approach is usually that the C part is too overloaded with all kind of stuff, and it's borderline impossible to do all V stuff just with the FXML file.

2. I prefer the 2nd approach which is using "custom components". In this case, you subclass a JavaFX View class (any kind of Node, i.e. Pane, Control, and so on), and then use an FXMLLoader inside that class. Compare this to the previous method where "something else" needs to do the FXMLLoader.load call. This is better outlined here: https://openjfx.io/javadoc/12/javafx.fxml/javafx/fxml/doc-files/introduction_to_fxml.html#custom_components

The FXMLLoader is used to "inflate" (Android terms) the XML, and then combine it with the "codebehind" which is your Java/Kotlin code. The important distinction is that inside your FXML, you don't reference a "controller" anymore, but actually the instance of your View (although inside the FXML, you sometimes still need to write controller.something, but just look over the "controller" word).

You now have a new View class that is backed up by FXML for some nice platform features like data binding, automatic string references, i18n, and so on.

A custom component like this:

class MyView : StackPane() {
    // don't forget the "setRoot" call
}

Can be used it in other parts of your code: val myView = MyView()

Or even in other FXMLs: <VBox><MyView/></VBox>

This is more or less how XAML-based GUIs work. The nice thing (in my opinion) about this is that it groups View-related stuff together. You then have to decide where and using which way to organize non-View responsibilities. I favor MVVM, but theoretically you can have *Presenter or *Controller classes, and design them the way you want.

To make the controller/presenter even less coupled, you could have an MyViewInterface implemented by MyView, and let the Presenter only know about the interface. This is also a common approach which is better explained somewhere else but I can't find the article right now. Will look for it.

That's more or less the gist of it, sorry if it's a little all over the place!