Is the goal to allow third-party plugins, or just to have your own codebase be very modular and reusable?
If the former, probably GenServers and Behaviours. Disclaimer: I haven’t built anything that allows third-party plugins, so I’m shooting from the hip. 
I think this would work though. Defining a behaviour with the public interface you want plugins to provide solves the same problem as interface injection in OOP languages. Making each plugin a GenServer provides process isolation, so a faulty plugin can’t crash the rest of the app.
If it’s just modularity in your own codebase, I’ve found in my Elixir projects that fancy patterns and indirection are usually not that helpful for improving the modularity and maintainability of my code. Just separating functions into different modules with clearly defined purposes and ensuring the different layers of the app only access modules from lower layers is the most important factor in my experience. It’s remarkably easy to just move a function or three into a separate module when everything is immutable and I don’t have to worry about the function mutating some global state in the module its defined in. Behaviours are still useful for defining some kind of contract between subsystems or different GenServers in the same application, but I think using them for code reuse is an anti-pattern, or at least can potentially be an anti-pattern. Similar to using inheritance to reuse code instead of using it to model the domain in OOP languages.
