Open Host Service & Published Language
debt(d7/e7/b7/t5)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints list deptrac and phpstan as tools, but detecting a missing or poorly designed OHS — e.g., direct model imports across context boundaries, no stable API contract, shared databases — requires deliberate architectural review. Deptrac can flag cross-boundary dependencies but won't identify whether an OHS is missing or shaped by a single consumer's needs. Most violations are invisible until integration pain accumulates.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix describes publishing a stable public API with versioning, but the common_mistakes reveal deeper issues: decoupling the Published Language from the internal domain model, adding a versioning strategy, and redesigning consumer-shaped APIs all touch multiple bounded contexts and consumers simultaneously. This is a cross-cutting architectural correction, not a local fix.
Closest to 'strong gravitational pull' (b7). The applies_to scope covers web and api contexts broadly. OHS defines the integration contract between bounded contexts — every upstream change, every new consumer, and every versioning decision is shaped by the OHS design. A poorly designed OHS (tightly coupled to internals, no versioning) imposes a persistent tax on all integration work across the system.
Closest to 'notable trap — a documented gotcha most devs eventually learn' (t5). The misconception field directly states the trap: developers conflate OHS with 'having a REST API,' missing that OHS is an architectural decision about interface ownership and consumer relationships. This is a well-known DDD gotcha — common enough to be documented — but it doesn't contradict a strongly similar concept from another domain, keeping it at t5 rather than t7.
Also Known As
TL;DR
Explanation
Open Host Service (OHS) defines a clear API contract (the Published Language) that downstream contexts use directly — typically an OpenAPI spec, event schema, or protocol buffer definition. All downstream contexts integrate using this one stable protocol rather than each negotiating a custom translation. Distinguished from Customer-Supplier: OHS publishes a general interface rather than tailoring it to each downstream. Distinguished from Shared Kernel: OHS is one-directional — upstream publishes, downstream consumes without tight coupling.
Common Misconception
Why It Matters
Common Mistakes
- Published Language tightly coupled to the internal domain model — decouple the public API representation from internal implementation
- No versioning strategy for the Published Language — breaking changes break all consumers simultaneously
- OHS shaped by one consumer's needs — the OHS should be designed for all consumers
- Treating every outbound API as OHS — reserve for contexts with multiple consumers needing a stable general interface
Code Examples
// No Published Language — N custom integrations:
// Orders → Billing: custom internal format
// Orders → Shipping: different custom format
// Orders → Analytics: yet another format
// Adding new consumer: negotiate a new custom integration
// N consumers = N integrations to maintain forever// Open Host Service — one stable Published Language:
// Orders publishes OpenAPI spec v1:
// GET /orders/{id} → { order_id, status, line_items, total }
// All consumers use the same protocol:
class BillingService {
public function processOrder(int $orderId): void {
$order = $this->ordersApi->getOrder($orderId); // Published Language
// No custom translation layer needed
}
}
// Adding new consumer: read the spec, integrate directly
// 1 protocol maintains instead of N