With the advent of Invocable actions, this has become one of my main architecture goals for all projects. Using Invocable actions, you can create libraries of tools that process builder can compose into functional data manipulation apps. So, when I say create tools, I mean build decision-making methods and data manipulation methods, but leave the two of them separate. This allows you to not only utilize the code in Apex, but to expose additional actions to the process builder and flows. Exposing functionality to the declarative development side of the platform empowers your admins and your development team alike to rapidly make alterations to business logic without having to deploy code. There's an intellectual cost to this method of development. Building methods that manipulate data in clear, predictable ways means your org swells with lots of methods. While numerous, they become a private API specific to your org that can be composed into bigger methods and applications. Build the APIs first, then compose those methods via process builder, flows, or Apex to establish the complex business logic.

I find that some developers find this intimidating and threatening. After all, building libraries of code that non-coders can utilize through declarative tools may seem like giving the keys to the kingdom away. But no amount of exposed Apex functionality used in processes or flows will ever replace the raw speed and flexibility of coding a solution. Exposing these kinds of data-manipulation methods for declarative development only helps the business move faster, while freeing us to do new and innovative things that only code can do.