I heard someone in the past who said that the Building Microservices book is the “DDD: The good parts” version of the Domain Driven Design book of Eric Evans (please note that none of these book have I read yet 
).
That statement, later on, I interpreted it to mean that microservices are the same as bounded contexts.
But a few days ago, as I was watching an interview of Uncle Bob Martin — “A Path to Better Programming • Robert “Uncle Bob” Martin & Allen Holub • GOTO 2021” — the interviewer, Allen Holub, made a statement which implies that microservices are not the same as bounded contexts! (in time 5:00 in the video)
— Of all the good things in that video, this is the one you remember most? —
Uhuh!
I don’t really know that much about microservices or bounded contexts. But because microservices seems hyped these days, those words coming out from master programmers, who have lots of skills and experience in software development, are very valuable — needs to be put in storage for future reference.
Related materials
“Bounded Contexts are NOT Microservices” by Vladik Khononov
“Tackling Complexity in Microservices” by Vladik Khononov
“Bounded Contexts, Microservices, and Everything In Between - Vladik Khononov - KanDDDinsky 2018”
Heuristic #1: Do not implement conflicting models in the same service. Always decompose to Bounded Contexts.
“The Single Responsibility Principle” by Uncle Bob Martin
… each software module should have one and only one reason to change… the reasons for change are people
“Single Responsibility Principle – do you know the real one?” by Bartosz Jedrzejewski
A module should be responsible to one, and only one, actor.
“The Single Responsibility Principle” by Juan Orozco Villalobos
The Misunderstood Single Responsibility Principle by Joseph Lynch
“Designing Microservice Architectures for People”
I would recommend starting with just one microservice per Bounded Context. Others can be extracted out only when there is a good reason to do so… This way, you defer all the additional complications that microservices bring until you know you need to face them.
“Domain-driven design needn’t be hard. Here’s how to start” by Andrew Hamel-Law
