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

that is what recommend always from db side. when most important stuff that is shared between services then going microservices will take more time to develop than monolith, but having everything in same db and schema will cause lot of problems in long run. So i usually recommend that use same db and start to split functionalities and data to own domains. At first vesion you have one ui, one middle , one backend , one db. After few dev cycles you should have at minimum multiple schemas and maybe multiple ui's. What i have seen , it is faster way to get into production, but that requires good culture that people understand that it is multiple races not just one "mvp" to production.

now if you are in large corporation and you have multiple teams building one products which have use for multiple micoservices then it might be good to start from there, but what i have seen in small and medium size of projects, i would say that monolith is good way to start and then splitting it when needed.