Lesson 125 - Managing Broad Bounded Contexts

A bounded context is essential for microservices, defining an encapsulated link between a service and its corresponding data. However, many times it is necessary to share data between multiple services, thus forming a broader bounded context. How do you managed these broader bounded contexts? In this lesson Mark Richards shows examples of why a broader bounded context is sometimes necessary in microservices, and through code examples shows some techniques for managing these broader bounded contexts.
Reference Links:
Software Architecture Monday: bit.ly/3dadEe3
Fundamentals of Software Architecture: amzn.to/3rgFLjY
Software Architecture: The Hard Parts: amzn.to/3BjMMF2

[@Nick-db1zp]

Is a data domain pattern similar to a mixture between microservices and service-based architecture?

[@markrichards5014]

Sort of; it doesn't have to be-you can still share data in a pure microservices ecosystem with single-purpose services (service-based uses domain services that are generally coarse-grained)

[@MrPrabakar007]

👍, very useful for microserive.

[@marcom.]

I like the explanation of the data domain pattern, but I think it's not a good idea to build a static enum with all known bounded context names. This leads to a lib that knows every single bc and has to be imported from every bc. This leads to some kind of coupling and frequent dependency updates. I think with modern IDEs you don't need such a construct to find out which code uses a specific datasource.