parameterizing-dependencieslisted

# Parameterizing Dependencies ## Overview Business logic frequently needs something from the world: a stored record, the current time, a rate from another service. Reaching for it directly makes the logic impure, untestable, and dependent on infrastructure it should know nothing about. The functional answer needs no container and no framework. The domain declares what it needs as a function type, receives it as a parameter, and the shell supplies the real implementation once, at the edge. Where possible the dependency is removed entirely, by fetching first and deciding afterwards. ## When to use - A domain function needs data it does not have - Tests require a mocking framework to run business logic - The current time, a random value, or an identifier must be generated - Deciding where to put a service call inside a workflow - A domain module imports a database or HTTP client Not for: choosing which effects the system performs at all, which is [separating-pure-core-from-shell](../separating-pure-core-from-shell/SKILL.md). ## The three strategies, in order of preference **1. Dependency rejection.** Restructure so the function does not need the dependency: fetch the data in the shell, pass the values in, and let the decision be pure. ```text -- before: the decision needs a lookup priceBooking : GetTreatmentPrice -> Booking -> PricedBooking -- after: the shell looked everything up first priceBooking : PriceList -> Booking -> PricedBooking ``` Best when the set of need