It isn't really brought out as much in the article as it should be ...
A key thing like about this architecture is it gets some of the benefits of microservices (codebases can be split, services deployed and managed separately, low coupling as a default) but without the downsides of fragmenting the data store, which causes a lot of the issues in a pure microservice architecture.
Once you fragment the data store you now have to fully compensate for the loss of transactional integrity at the data layer. It also forces a coherent data model across all the services - no more "service X" has a slightly different model of a data type to "service Y" - there literally is only one definition of the data type.
So I see it as a reasonable midpoint between monolith and microservice that gets most of the benefits of microservices without the most severe drawbacks.
A key thing like about this architecture is it gets some of the benefits of microservices (codebases can be split, services deployed and managed separately, low coupling as a default) but without the downsides of fragmenting the data store, which causes a lot of the issues in a pure microservice architecture.
Once you fragment the data store you now have to fully compensate for the loss of transactional integrity at the data layer. It also forces a coherent data model across all the services - no more "service X" has a slightly different model of a data type to "service Y" - there literally is only one definition of the data type.
So I see it as a reasonable midpoint between monolith and microservice that gets most of the benefits of microservices without the most severe drawbacks.