> I have found myself tending more and more towards a style where I break even some relatively small modules up into fairly small pieces, and I have very, very clearly specified definitions for "what this module consumes" and "what this module provides".

I have found this exact thing to be a very natural fit for functional programming. Which is also why I switched from Ruby (where I was already starting to write in a functional style anyway, for these exact reasons) to Elixir (which basically tries very hard to prevent you from writing in a non-functional style while also giving you guarantees that are simply not available in a mutable procedural/OOP language).

The vast majority of application code can be rewritten in such a way that it takes some struct or data, and spits out some struct or data, and has no other side effects (which include mutating the structs or data originally given to it). You can confine the side-effecting code to its own interface code... a principle embraced by https://blog.ndepend.com/hexagonal-architecture/ (also a natural fit for functional languages, but can also be utilized in OOP)

The advantages of this design end up being numerous: easier unit-testability, easier reasonability, easier maintainability, fewer dependencies, fewer bugs generated.