# Context Mapping: Integration Patterns > [!Note] > Integration patterns in [[Context Mapping]] define how [[Bounded Context]] relate, collaborate, and translate between their **domain models**, ensuring clear **contracts**, controlled **dependencies**, and preserved **autonomy**.` **Context Mapping** is the practice of explicitly defining the relationship between two [[Bounded Context]] as a technical and collaborative contract. These **integration patterns** establish the rules by which teams work together or isolate themselves, specify how models are translated or shared, and document the responsibilities and artifacts required to maintain stability. By selecting the appropriate pattern, teams can balance **coordination** with **independence**, tailoring integration strategies to the needs of each context pair. --- ## Summary Table |Pattern|Purpose|Key Concepts & Artifacts| |---|---|---| |**Partnership**|Two teams collaborate closely, evolving their models together with shared CI/CD|Shared backlog; common pipelines; dual responsibilities| |**Shared Kernel**|A small, jointly maintained core subset of the model used by both contexts|Common entities/value objects; version governance; review board| |**Customer–Supplier**|An upstream supplier offers a clear contract that downstream customers consume|Public contracts (APIs/events); SLAs; consumer-driven tests| |**Conformist**|The downstream team accepts the upstream model “as is,” avoiding local adaptations|Unmodified acceptance; risk of lexical contamination| |**Anti-Corruption Layer**|An adapter layer translates and shields the core domain from external models|Adapters/translators; DTOs; mappers; isolated integration tests| |**Open Host Service**|A context exposes a versioned, secure synchronous service for other contexts|Public API (REST/gRPC); versioned contract; access controls| |**Published Language**|Emission of events or documents in a stable, standard format for asynchronous subs.|Schemas (JSON, Avro); messaging channels (Kafka, MQ); versions| |**Separate Ways**|Contexts evolve entirely independently with minimal integration or data duplication|Independent models; separate databases; ETL or batch processes| --- ## References - Vernon, V. (2016). _Domain-driven design distilled_. Addison-Wesley Professional. - Vernon, V. (2013). _Implementing domain-driven design_. Addison-Wesley Professional. - Khononov, V. (2021). _Learning domain-driven design: Aligning software architecture and business strategy_. O’Reilly Media. - Alammar, J., & Grootendorst, M. (2024). _Hands-on large language models: Language understanding and generation_. O’Reilly Media. - Evans, E. (2003). _Domain-driven design: Tackling complexity in the heart of software_. Addison-Wesley Professional. - Millett, S., & Tune, N. (2015). _Patterns, principles, and practices of domain-driven design._ Wrox.