Open Host Service
An upstream designs and publishes an explicit service contract for multiple consumers.
- ProviderPublishes contract and version.
- ConsumersUse shared capability.
- ProtocolGoverns integration and compatibility.
Context
Why this is important
Provide a reusable upstream capability as a stable contract for several consumers.
A relationship between Bounded Contexts in strategic Domain-Driven Design.
Shared service and bespoke integration
The shop remains a modular monolith with seven modules and a shared deployment; this relationship describes model ownership.
This is how you read the picture
- Provider Upstream
- Consumers Downstream
- Protocol Published contract
| Aspect | Open Host Service | Point-to-point |
|---|---|---|
| Consumers | Many use shared contract | Coordinate each connection separately |
| Change | Versioned and documented | Multiple bespoke cases |
| Domain model | Translate when needed | Often directly coupled |
Benefits & limitations
Helps if:
- Several consumers need a shared capability with clear ownership.
- Contract, versioning and compatibility can be documented openly within the organisation.
Boundaries
- A shared service becomes a bottleneck when every consumer demands bespoke contracts or changes.
- A technical API contract does not replace business translation between different models.
In practice
- Identify recurring capabilities and consumers before defining a shared contract. Record which needs are common to all consumers and which they translate at their own boundary.
- Document operations, semantics, error responses, versioning, and compatibility rules in a service contract accessible to all consumers. Have owners announce changes and deprecations early.
- Test the contract with at least two consumers and observe shared needs as well as special cases. Evolve the offer based on real integrations without adding every local model to the upstream contract.
Read the detailed explanation
Open Host Service is a Context Map pattern for a reusable upstream capability. The provider publishes an explicit service contract with protocol, versioning, and operational ownership for multiple downstream contexts to integrate against. The offer reduces individual point-to-point agreements when consumers can work with a shared contract.
Published Language is a separate Context Map pattern: it defines a shared language or exchange format for integration and can be combined with an Open Host Service. Consumers translate that format into their own model when needed. A service contract alone does not unify domain models.
The pattern names an upstream capability for many clients in the Context Map; an Anti-Corruption Layer protects a consumer from foreign domain language.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Who owns versioning of the shared service?
View the solution with justification
The upstream provider documents and owns its published contract.
ApplyingTransferred to a new situation
Wie kann die Ordering den Katalogvertrag nutzen und ihr Modell schützen?
View the solution with justification
It uses needed contract fields and translates them into its index model.
EvaluateWeighing an alternative
When does a shared service become a bottleneck?
View the solution with justification
When bespoke demands from many consumers dominate shared evolution.
Explore further
These building blocks continue the thoughts of this page.
References
- Eric Evans · DDD Reference (opens in new tab)Primary reference on Context Mapping and relationship patterns.
- Vaughn Vernon · Implementing Domain-Driven Design (opens in new tab)Practical book on context boundaries and team relationships.
- Domain-Driven Design Reference · Strategic Design (opens in new tab)Terminology reference for strategic DDD.