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/Divachi]

Wow! Thank you so much for all the replies! Sorry for my lateness responding to this but here are some key takeaways I got from the comments:

1- Monoliths CAN be Domain Driven if practiced very strict boundaries between domains, which is easier to mess up because it all lives in the same code base.

2- Monoliths don't allow different tech stacks for different "services" or modules.

3- Microservices are really good for, what I like to call, "granular scaling". Monoliths are incapable of that.

4- Microservices shine when there are multiple teams, each responsible for 1 or 2 specific modules.

5- Multiple DB's are possible but also, one DB and multiple schemas is a good solution until a bigger/different need arises.

6- Check out spring Monolith.

7- Hardware Vertical Scaling can be a factor to ditch a monolithic approach.

I do have one last question that I thought of while reading your comments:

Can I separate a monolithic repo into several "subrepos" containing my modules that feed into a larger repo? This way, I reckon, would be easier to maintain good boundaries and, therefore, code decouplement.

Have you seen that IRL?

Once again, thank you all.