I do agree with you when you say "how an app is distributed" in that monolithic does not necessarily mean disorganized and poor coding patterns, and I realize that this post does not highlight that fact well. I have updated various parts of it to reflect this and want to thank you for pointing this out!
The intention in the post was to highlight the difference between having files that circularly referenced each other (i.e. poor "n-tier" design), but what I failed to mention was what you pointed out on how this problem can arise even in a microservices architecture. The first example is a "Poorly designed monolith" while the second example is a "Well designed monolith".
And finally, to your point on monolithic architectures getting bad press, I definitely agree. From my experience, I would say that anything you are designing from scratch (i.e. you have a general idea how to build it, but not enough foresight to fully plan) should start as a monolith and get refactored in only the places where it is truly necessary.
About the levels of quality you can find inside a monolith, I am experiencing right now the curious situation of how, in order to be able to extract some functionality out of a poorly designed monolith to some separate service, the process of decoupling and isolating the code is leading to some decent implementation of it and removing the need of a new service and all the burden it implies in terms of communication, testability, etc.
As you point out in your post, the simplest choice that covers your quality needs is the way to go.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I do agree with you when you say "how an app is distributed" in that monolithic does not necessarily mean disorganized and poor coding patterns, and I realize that this post does not highlight that fact well. I have updated various parts of it to reflect this and want to thank you for pointing this out!
The intention in the post was to highlight the difference between having files that circularly referenced each other (i.e. poor "n-tier" design), but what I failed to mention was what you pointed out on how this problem can arise even in a microservices architecture. The first example is a "Poorly designed monolith" while the second example is a "Well designed monolith".
And finally, to your point on monolithic architectures getting bad press, I definitely agree. From my experience, I would say that anything you are designing from scratch (i.e. you have a general idea how to build it, but not enough foresight to fully plan) should start as a monolith and get refactored in only the places where it is truly necessary.
My Monolith SJW spirit feels way more calm now :D
About the levels of quality you can find inside a monolith, I am experiencing right now the curious situation of how, in order to be able to extract some functionality out of a poorly designed monolith to some separate service, the process of decoupling and isolating the code is leading to some decent implementation of it and removing the need of a new service and all the burden it implies in terms of communication, testability, etc.
As you point out in your post, the simplest choice that covers your quality needs is the way to go.