Would you have the quote on that? I'm curious.
In my opinion, Microservices is an implementation detail, and the extend to which DDD principles are applied is about people and ownership.
In my opinion, Microservices is an implementation detail, and the extend to which DDD principles are applied is about people and ownership.
From my experience, breaking down a monolith without first identifying and isolating its bounded contexts (as in DDD) is a recipe for disaster. With your domains completely entangled in a single codebase, you won't pull only what you want and you will have to bring a lot of undesired code, behaviours and side effects with it.
The safest recipe, in my opinion, is to break down your monolith in bounded contexts (or ideally, to have focused on it from the start), so you can better reason and understand the advantages and trade-offs of moving each specific domain and responsibilities out of your unique codebase.
I saw often teams being motivated in moving their code out of a legacy codebase because of the huge technical debt, but they were bound to suffer a death of a thousand cuts by just bring the same debt in a new service, and adding network constraints on top.
It is. But it's a very strong one, where it's harder to blur the boundaries because you're putting your code into a service or another.
And that's the advantage. Not because it's easier to apply correctly. But because it's harder to do it badly.
And if you do it badly, it will show and the product performance will be a mess.