Trying to force fit a monolith/modulith is also a problem. I've seen overreactions to fears about having separate services create suboptimal solutions. The real answer is that you have to make the right solution for the problem you're facing without lapsing into a dogma. Humans tend to be pretty bad at this and want simple rules of thumb. The only rule I would endorse almost blindly is, don't start with microservices. The rest depends on what happens with your business and in what time frame. After building a company from scratch to 15 devs and experiencing tons of services at Spotify, I would recommend:
- monolith to start with very little time spent on code architecture patterns like DDD (although these days with llms I would say go for it and use DDD patterns in your prompts)
- optimize code cleanliness by adhering to better code architecture patterns
- when it feels like you are doing weird things to scale a process on the monolith (scheduling background tasks where you could break out a pubsub to function service and defend your uptime while coordinating on a shared DB), drop any religion around no micro services.
- monolith to start with very little time spent on code architecture patterns like DDD (although these days with llms I would say go for it and use DDD patterns in your prompts)
- optimize code cleanliness by adhering to better code architecture patterns
- when it feels like you are doing weird things to scale a process on the monolith (scheduling background tasks where you could break out a pubsub to function service and defend your uptime while coordinating on a shared DB), drop any religion around no micro services.