This is only possible if you can precisely draw business domain boundaries. Micro-services add large operational overhead. If you slice you application in wrong way you will suffer...
IMO it is better to start from monolith and then extract services.
There aren't any micro-services in our applications. However, drawing business boundaries is much easier to do in Clojure than most languages I've used.
You have a common set of data structures that all functions operate on. To create a piece of domain logic, I simply need to create a namespace, and put the related functions there.
This style of code is highly composable. Since majority of functions are doing generic transformations, the domain specific logic is expressed by chaining these functions in a particular way to get a desired transformation. When I need a different kind of transformation, then I just chain the functions in a different order. My experience is that the business logic naturally bubbles up to a thin layer at the top.
My team has been working with Clojure for the past 6 years, and we've built and maintain a number of large applications. Dynamic typing is absolutely not a problem for us.
I find that immutability plays a far bigger role when it comes to maintaining large applications. When you work with immutable data, it becomes possible to safely reason about parts of the application in isolation. This is a key factor in making large apps maintainable.