Context Mapping

Context mapping names the relationship between bounded contexts deliberately, instead of letting one model silently bleed into another. Evans catalogs several: partnership, shared kernel, customer-supplier, conformist, separate ways, and a defensive Anti-Corruption Layer, with Open Host Service and Published Language for a shared integration surface.

The map is socio-technical, and that too is Evans’s own: his customer-supplier and partnership patterns are defined in terms of teams, not just code. That makes it a complementary lens to Team Topologies’ team-interaction modes rather than a rival. DDD’s context map is the finer-grained of the two, and the gaps run both ways, so keep them distinct rather than collapsing one into the other.

Signal: every boundary between contexts has a named, deliberate relationship, and you can say which team owns each side. Part of Domain-Driven Design.

Sources

• Eric Evans, Domain-Driven Design Reference (2015): the customer-supplier and partnership relationships, defined in terms of teams and not just code.
• Matthew Skelton and Manuel Pais, Team Topologies (2019): the team-interaction modes the context map is a complementary, finer-grained lens on.