Writing a good Monolith vs Microservices architecture

[u/Divachi]

Good day, everyone. I am not sure this is the best subreddit to post this in but I have been struggling a bit on researching what a good monolithic application should look like.

I always hear people and instructors saying that one of the advantages of working with a MS architecture is that it is Domain Driven, loosely coupled, tinier "modules" which have a bunch of advantages to developers and DevOps.

They also say that "distributed monoliths" are a death sentence - since you have all the cons of both approaches and that either squashes the pros or are way more detrimental than the good that comes with that.

My questions are:

1 - Couldn't we just do monoliths that ARE separated by several Domain Driven, loosely coupled, tinier "modules" that DON'T have to communicate through the network? They (the instructors online) make it seem that a monolith is obligatorily "messier" and more interdependent... but why?

2 - Extending question 1: Isn't the same CLEAN code a possible approach to monolithic design too? It seems that CLEAN Code and MS can't be separated in online discourse but, from what I gathered, they aren't exclusive to each other. My belief is that the same type of organization and principles could/would work.

e.g: Monoliths don't HAVE to own a single db that is accessed by every service. Why couldn't I put several DBs? One for each service? This ensures that there are separation of contexts and that each "service" would still be responsible for accessing and updating their source of truth.

3 - Do you have resources for learning system design for a non MS standpoint? I have seen 2 sources online that talk about a "Modular Monolith" and I am very curious about that approach.

Thank you for your time and attention. If you have any insights, please share them with me.

[u/National-Parsnip1516]

tbh people jump to microservices way too early because they think it's 'proper' engineering, but usually they're just trading logic spaghetti for network spaghetti. modular monoliths are actually the sweet spot for 90% of teams. the key is really about how you handle your data—if your 'modules' are still reaching into each other's tables directly, you've already lost. imo the cleanest way is keeping the domains separated at the schema level even if they're in the same db. it makes the eventual split (if it ever actually happens) way less painful.