Hi Jose; thanks for the response!

Your question is an interesting one. My perspective is that Modules and Bounded Contexts are orthogonal concepts. I’d think of a Module as a deliverable unit, an artifact that one or more engineers might produce. A Bounded Context is more conceptual; it defines the entire domain that a given team is responsible for, e.g. the shared language and understanding that the team uses, the applications and services that the team produces, etc.

So for example, a Module might be developed and used by a single team, and would thus belong within a Bounded Context. However, Modules are usually things that are shared across teams.

So with your example, it depends on how your org is using the model of countries/provinces/cities/etc. If your org has some unique specialty in that area such that it’s a major line of business (maybe you’re a shipping company) then I could see a Bounded Context encompassing this modeling. Otherwise, if you’re talking about providing a common mechanism to help the teams in your org define addresses, then you’re probably talking about a Module (or, perhaps, a platform, which in itself begs an interesting question… would we consider a platform team to be its own Bounded Context?)