> Because by my personal experience, you totally can code a monolith in a strictly modular fashion, with clean interface-based API boundaries between the separate parts.
This is my experience as well. In fact, that's exactly how we transformed a spaghetti mess monolith into something that was still a monolith, but clean and well abstracted. As things evolved, we even split some of the interfaces out into first-class web services that we hosted on different infrastructure. It was a near-trivial operation.
For me, adhering to Service Oriented Architecture has been the consistent them of keeping things manageable. Thinking about who "owns" data vs. who "uses" it, how data from these different domains is linked, and keeping things modular and logically distinct are the real keys. This applies on the whole spectrum from monolith to microservices, and makes for maintainable code where key functionality can easily be split out if needed.
This is my experience as well. In fact, that's exactly how we transformed a spaghetti mess monolith into something that was still a monolith, but clean and well abstracted. As things evolved, we even split some of the interfaces out into first-class web services that we hosted on different infrastructure. It was a near-trivial operation.
For me, adhering to Service Oriented Architecture has been the consistent them of keeping things manageable. Thinking about who "owns" data vs. who "uses" it, how data from these different domains is linked, and keeping things modular and logically distinct are the real keys. This applies on the whole spectrum from monolith to microservices, and makes for maintainable code where key functionality can easily be split out if needed.