Bit of a rant, sorry. Skip if you are not in the mood for one.
I would challenge even that. I worked with Java for 8-9 years and I worked with it in its heyday (and I dropped it when it became too crazy and “programming” in Java was 80% writing XML and 10% writing .properties files). The other 10% you maybe wrote some Java. 
Those “patterns” helped only insofar as everyone was using them and thus onboarding in other people’s code was accelerated and made easier. They didn’t help with much else otherwise. They were like 90% social norms and 10% legitimately helpful ways of manipulating data via standardized code that made it future-proof-ish.
I also believe the entire “patterns” wording is quite unfortunate and does not at all capture the idea. “Dependency inversion” is just “don’t just pass one of the 17 implementations of this contract as a parameter to the using function, you idiot, use configuration!” and nothing else. “Factory pattern” is more or less “you don’t know the internal invariants of this data structure so please use a dedicated creator function for it and don’t try to be clever by directly setting the fields yourself”. Etc.
These should be common sense and should not be called “a pattern”; more like “an engineering guideline”.
That whole terminology only serves to make guys in suits-and-ties feel special and label themselves as consultants and bill insane sums of money for scratching their beards in meetings. Change my mind. 
(It’s going to be hard because I’ve seen how they work, closely, several times in my career, and was not impressed. Of course it could also be bad luck, sure.)
On topic: for FP I think #1 principle would be: make the thing you want to manipulate composable and pipe-able (reference: Ecto.Query, Ecto.Multi, Stream). Make it so you can manipulate the thing and accumulate / modify state captured inside of it. Make it so this can be done by any function abiding to a certain contract. Finally, invoke a function that actually “executes” what this thing represents (like Repo.transaction actually does all the DB operations accumulated inside an Ecto.Multi; while at the same time Ecto.Multi.insert function does nothing but put a state/command inside the Ecto.Multi that says “OK, when this Multi gets executed, we want to create this DB record”).
I have very small amount of failures in my career (although they make up for it being hugely embarrassing! ) and the “patterns” thing very rarely clicked with me, or most teams I ever worked with for that matter. People just organically and iteratively find what works best for their project. Stuff like “hexagonal architecture” or “functional core, imperative shell” are in general very good ideas and are emergent properties of most projects. I do like them but they too are not universally applicable.
