if you're not sure what the correct decomposition of responsibilities into services / components / libraries is, that suggests structuring the project in a way

if you're not sure what the correct decomposition of responsibilities into services / components / libraries is, that suggests structuring the project in a way (at least initially, until you're feeling highly directional pain to suggest a refactoring direction) that the cost of rearranging responsibilities is low. as well as starting with a monolith, that also suggests starting with everything in the one source control repository to make it trivial to refactor and rearrange across swathes of code in lockstep. in some organisations the amount of meetings and overhead scales proportionally to the number of network connections in the architecture diagram, so that also suggests replacing external dependencies with in-process function calls wherever possible.