In theory, that might be true, but in my experience it is not. Data is a very complicated part of microservices and the bounded context, and many times we are forced to weaken the bounded context to share a data context between several services. Within a bounded context containing processing, data, and request granularity (orchestration), sometimes there are good reasons to still break apart services (code changes, scalability, security, fault tolerance, etc.) and still share data. That would form a lose bounded context between multiple services and shared data.
Unbelievable demonstration!
Thanks Shireef!
Very informative video - thank you Mark!!
Glad you enjoyed it!
Very useful way to identify granularity! Thanx!
Thanks Mark, Can you share a sample project or links, how this can be done?
Best Regards From Mexico City. Manuel Silva.
¡Gracias!
IMO, DDD approach to identify Bounded-Context is better than this approach
So one bounded-context = 1 microservices
In theory, that might be true, but in my experience it is not. Data is a very complicated part of microservices and the bounded context, and many times we are forced to weaken the bounded context to share a data context between several services. Within a bounded context containing processing, data, and request granularity (orchestration), sometimes there are good reasons to still break apart services (code changes, scalability, security, fault tolerance, etc.) and still share data. That would form a lose bounded context between multiple services and shared data.