Behaviours are formalizations of these common patterns. The idea is to divide the code for a process in a generic part (a behaviour module) and a specific part (a callback module).
The generic part should be kept where shared/reusable code is kept. The specific part should be with the other code that implements a specific capability.
However if a Behaviour only exists to make testing more flexible rather than capturing some generic aspect then it simply belongs with the capability it supports.
Note that I’m assuming an organizational principle where code is organized by capability rather than collecting “like things” in folders.
And while Erlang has gen_server, gen_statem, gen_event there are behaviour modules that don’t have the gen_ prefix (e.g. supervisor). And just because you implement a gen_server doesn’t mean that the call module will necessarily have a _server suffix.
I think it is the real dispatcher.
In terms of that particular capability that is likely correct but that doesn’t take away from the fact that dispatcher.ex is intended to be the foundation for a whole family of dispatcher implementations.
