We have being implementing solutions for 3-4 years now in f# where we have adopted a "functional style" approach and we do alot of what you have described above and more. We dont implement classes (unless we have to), we use modules with grouped related functions that are glued together in workflows (which are themselves just functions.
We place full emphasis on type driven development where sum types (i.e. discriminated unions) and product types (i.e. tuples) play an integral role to enable us to express the intent of the code. Functional patterns such as partial application, function composition and pipelines are things we lean upon heavily.
Lastly we really emphasize on separating pure functions from functions that contain side effects, we have played quite a bit with category theory and we are using some monadic composition in some places albeit not substantially.
If I'm honest I'm heavily influenced by the likes of Haskell, powerful type system with emphasis on separating out side effects on their own. The struggle for us for quite a while was understanding how to construct actual production ready applications e.g. how do you manage dependencies in an elegant way, and how do we test functions that contain dependencies etc, in particular when there really isn't much out there for developing f# applications like I am describing. In truth, we have learned by looking at other functional language ecosystems.
Very refreshing read to see others thinking along the same lines as we currently are, thanks for sharing
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.