Sorta. I'd advocate for separating the deployment story (which might be simple or might be something complicated like microservices) from the development story

Sorta. I'd advocate for separating the deployment story (which might be simple or might be something complicated like microservices) from the development story (needing to add :checkouts to your lein project and/or manage multiple nREPLs is a real headache). The way most libraries get written, you end up with a namespace or two that matters. If you have three conceptually independent services, put them in separate namespaces like foo.bar, foo.baz, and foo.quux. If you later find the project is too large to manage, you can just move directories containing namespaces. Until then, you can use facilities in leiningen or boot to spit out multiple jars, or a single jar that can run multiple services (perhaps based on flags you invoke or a class you load). Further, until you need to have separate services, I'd probably just load all of them in the same process. Through all of this, your development story is much nicer, and there are fewer git repos to reason about. If you really do think you'll eventually need different git repos for your services, you might consider prefixing commit messages based on the logical service they relate to, so that you can migrate the history easily later on in an organized and linear way.