Exercise 3: A Genuinely Safe Relaxed-Layering Read — Possible Solution
====================================================================

THE NEW METHOD
------------------------------
    class OrderRepository:
        # ...existing save()/get() unchanged...
        def order_exists(self, order_id):
            return order_id in self._orders

A NEW PRESENTATION FUNCTION CALLING IT DIRECTLY
------------------------------
    def display_order_confirmation(repository, order_id):
        if repository.order_exists(order_id):
            return f'Order {order_id} found.'
        return f'Order {order_id} not found.'

VERIFYING IT WORKS CORRECTLY, CALLED DIRECTLY FROM PRESENTATION
------------------------------
    Order ORD-1 found.
    Order ORD-999 not found.

Both a real, saved order and a nonexistent one are reported correctly,
with presentation talking straight to the repository - no OrderService
involved anywhere in this call.

WHY THIS IS GENUINELY SAFE, WHERE display_order_total_broken() WASN'T
------------------------------
order_exists() answers a question with NO business rule attached to it
at all - "was something stored under this ID" is a pure fact about
storage, not a decision. There is no version of "does this order exist"
that a business layer could compute differently depending on loyalty
status, promotions, or any other rule - unlike get_order_total(), which
this chapter's own OrderService.get_order_total() showed genuinely
depends on business logic (the loyalty discount) to be correct.

Presentation calling order_exists() directly can never produce a wrong
answer, because there is no "right answer according to the business
layer" that a shortcut could miss - the business layer would just call
repository.order_exists(order_id) and return the identical result
itself, adding a pass-through method with zero actual logic in it.
display_order_total_broken() was unsafe specifically because
OrderService.get_order_total() does something - it doesn't just pass
the raw value through, it decides whether to discount it - and skipping
past that decision-making layer is exactly what produced the wrong
$100.00 result this chapter verified.

WHY THIS WORKS AS AN ANSWER
------------------------------
The new method is a genuine read with no possible business logic to
apply to it, verified working correctly when called directly from
presentation, and the safety argument is grounded in this chapter's own
distinction (does the business layer's own version of this call do
anything beyond passing the value through) rather than a general claim
that "read-only" is automatically safe.