Thanks for taking the time to read the article, and for providing thoughtful feedback. I honestly appreciate it, whether in agreement or disagreement with what I’ve written. With that… a few responses. :)
1. I didn’t say “no core services”, and there’s a reason for that: I don’t believe there should be literally no “core services.” I indeed mention that certain core services are unavoidable/useful; again, that was on purpose.
The problem arises when one team is granted responsibility for the data that other teams consume. Chris Richardson gave a great interview on InfoQ that discusses the dangers of runtime and design-time coupling. The “core services team” model leads to this coupling. It also runs counter to the notion that teams should manage their own data.
I’d also add that the example I gave was not hypothetical; it was a real one. I’ve encountered other similar, problematic examples. With that said, I’d be interested in learning about any experience where the model has shown to be optimal.
2. I agree that neither Event Sourcing nor CQRS is the only way to build microservices. But I didn’t actually broach either of them in the article, and I’m scratching my head as to where you saw them mentioned. Publishing events is not the same as Event Sourcing or CQRS, nor is taking into account the difference between commands and events when designing systems.
3. I can see how my use of “vertical” and “horizontal” can be unclear, or perhaps counter to their use elsewhere. My use of “vertical” is intended to mirror its use in terms like “product vertical.” Meaning that we should favor team boundaries drawn as vertical boxes so that they include the required disciplines, rather than as horizontal boxes, which would group together engineers of the same discipline. It sounds like we agree on the concept; it also sounds like I should work on disambiguating my terminology.
4. I’ve actually been mulling over whether the usefulness of microservice stereotypes is diminishing, so your feedback validates that mulling. Not because there is anything inherently wrong with multiple services — each with a specific purpose — within a given domain/bounded context. But mainly with the advent of, e.g, GraphQL, which subsumes multiple individual patterns, and trends like “macroservices”, where teams maintain a single service — rather than multiple microservices — for their entire domain. (And yes, I know that even Martin Fowler considers data services in particular to be an anti-pattern — there are a few reasons I don’t 100% agree, but that’s a whole other topic).
