Monolithic software maintained in a single computer/repository is so much better than software spread across many computers and repositories. There are some first-order arguments against a monolithic codebase, but the higher-order points will win out every time. I.e. the reason you want a separate codebase for each "concern" is probably because no one figured out how to work together as a team toward a common objective. This lack of teamwork will ultimately kill your project if you do not resolve it, so whether or not you do microservices in the expected way (i.e. HTTP RPC) will make no difference either way.
If you still want "micro" services because it actually makes technological sense, you can build these at a lower level of abstraction under some /Services folder. Many languages have namespaces, which allow for boundless organizational schemes. Only for a lack of imagination would you fail to organize even the most complex of applications in this manner.
If you still want "micro" services because it actually makes technological sense, you can build these at a lower level of abstraction under some /Services folder. Many languages have namespaces, which allow for boundless organizational schemes. Only for a lack of imagination would you fail to organize even the most complex of applications in this manner.