> Almost always a monolithic with some SOA and clear domain boundaries is going to work better for static/slow growth teams.
If it has “some SOA and clear domain boundaries” its not a monolith, even if it isn't decomposed so far as to be microservices.
“Right-sized services” isn't a catchy meme-spreading label, but it's probably the synthesis pointed to by microservices as the antithesis to monoliths.
Monolithic just means it can carry out all it's required functionality alone, i.e. it's [major] dependencies are internalized.
It doesn't say anything about not being able to be broken into modularized sections, services, or domain boundaries.
Neither does it reject any setups where satellite systems, micro or otherwise make use of the monolith programmatically or otherwise, hell it's kond of part of the definition of a monolith that it has multiple access points (i.e. cli, sdk, rest, rpc, events.)
It's the thing you reach for when you're hiring a new team worth of developers every other week and can't avoid developer blockage any other way.
It's not even a good architecture for most of the things it ends up being used on.
There are very few problem sets that a microservices arch actually excells at.
Almost always a monolithic with some SOA and clear domain boundaries is going to work better for static/slow growth teams.
It might be exciting for some but I wouldn't wish it on anyone.