Third anti-pattern. Dependencies are 'opaque' when the handler can't see or control them. Two flavors discussed: (1) opaque projections — the framework hands the handler an already-projected entity, so beginners can't find the event sourcing in the code and caching/snapshotting strategies can only be set through global config or class macros (and sometimes no entity is even needed — email-uniqueness via a reservation event, updating materialized views, telemetry handlers); (2) opaque writers — the handler returns events and defers writing to an external actor, which means the handler is incomplete (the write may still fail), generic failure handling has to be centralised, and countermeasures like 'expected version' for concurrency cannot be chosen per case (mandatory for racing command submissions, but unwanted after irreversible external effects like a Stripe charge). Ladd argues controlling one's dependencies is fundamental and repeatedly overlooked — gems like VCR or global database mocks have trained programmers to avoid it.