I tend to think of code in a cellular sense, as in, biology. Outside the cell is a big scary world that you don't control. There's a cell wall where you only permit certain things in. Inside the cell, the cell trusts that only good stuff has been let in. It may also have to package certain things on the way out to the next cell.
In this case, the observation I'd make is about that big scary external world. You don't get to impose anything on it, or at least, your control is a great deal less rigid than our code would like. Even if you think you control your internal network, hackers might explain otherwise to you in the worst possible way. You can't impose compliance with functional paradigms, imperative paradigms, security levels, soundness of data, whether or not a bit was flipped during transit, that the metadata matches what was sent, or anything.
Obviously you can't fully write your code that way (even real cells get it wrong sometimes too), but that's the principle I try to view the world through. Even within an application where every individual component is, say, compliant with functional programming, the interactions still can't be counted on to have any particular properties that you don't check somehow.
FP, OO, data-driven design, all that sort of stuff, that's for what you do inside the cells, and maybe how you choose to structure the code implementing your cell wall. But you almost always end up forced to treat the outside world as bereft of any structure you don't rigidly check for and enforce yourself, if not outright hostile (anything with security implications).