# Bounded Context Relationships and Power

*MuleSoft Platform Architect Study Guide · Designing and sharing APIs · Last updated November 13, 2026 · https://www.certifyforce.com/study-guide/mulesoft-platform-architect/designing-and-sharing-apis/bounded-context-relationships-and-power*

Choose context-mapping strategies from delivery dependence, influence and model ownership. Use a realistic context map to distinguish coordination, shared models, upstream conformity and protective translation.

- Certification: Salesforce MuleSoft Platform Architect
- Exam section: Designing and sharing APIs
- Study guide: https://www.certifyforce.com/study-guide/mulesoft-platform-architect

**Official exam objective:**

> Given a specific power relationship between two Bounded Contexts, choose the most appropriate strategy for mapping between the API data models of these Bounded Contexts.

## What the exam expects

- Distinguish mutual delivery dependence from an upstream/downstream relationship.
- Select a collaboration strategy from the teams' influence and commitments.
- Separate a deliberately shared model subset from translation between models.
- Decide whether a downstream context adopts the upstream model or protects its own.
- Read the existing context relationships before proposing an integration design.

A **bounded context** defines where a model applies; **upstream** can affect downstream success while succeeding independently; **translation** maps between models; a **context map** records their relationships; a **ubiquitous language** connects the team's model, communication and code.

## Key facts

| Fact | Detail | Source |
|---|---|---|
| Partnership | Coordinate planning and integration for mutually dependent deliveries. | [DDD Reference](https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf) |
| Shared Kernel | Keep the jointly shared model/code subset small and explicit. | [DDD Reference](https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf) |
| Kernel changes | Consult the other team and coordinate integration. | [DDD Reference](https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf) |
| Customer/Supplier | Factor downstream priorities into upstream planning. | [DDD Reference](https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf) |
| Acceptance tests | Joint tests validate the downstream interface expectation upstream. | [DDD Reference](https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf) |
| Conformist | Downstream accepts the upstream model to simplify integration. | [DDD Reference](https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf) |
| Anticorruption Layer | Translate upstream functionality into the downstream's own model. | [DDD Reference](https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf) |
| Current map | Record existing contexts and relationships before transformations. | [DDD Reference](https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf) |

## Check yourself

- Why should a context map start with the relationships that teams actually work under?
- When a neighboring subsystem is not object-oriented, what still belongs in the map?
- Which shared vocabulary should include the bounded contexts' names?

## Sources

- [Domain-Driven Design Reference — Eric Evans](https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf)
- [Common API mistakes](https://blogs.mulesoft.com/dev-guides/common-api-mistakes/)

## About the full unit

The "Core concepts", "Exam traps" and "Worked scenario" sections of this unit, its 5 linked practice questions, and unlimited timed mock exams are included with the MuleSoft Platform Architect pack (USD $19): https://www.certifyforce.com/practice-exams