The Generated Boundary

We’ve spent a little time in the functional core, and we’ve seen that our schema and changeset code is predictable and certain—it behaves the same way given the same inputs, every time. In this lesson, we’ll shift away from the core and into the places where the uncertain world intrudes on our beautiful assumptions. We’ve come to the Phoenix context.

Phoenix Context

Contexts represent the boundary for an application. As with all boundaries, it defines the point where our single purpose code meets the world outside. That means contexts are APIs responsible for taking unsanitized, unvalidated data and transforming it to work within the core, or rejecting it before it reaches the core.

The boundary code isn’t just an API layer. It’s the place we try to hold all uncertainty. Our context has at least the following responsibilities:

• Access External Services: The context allows a single point of access for external services.

• Abstract Away Tedious Details: The context abstracts away tedious, inconvenient concepts.

• Handle uncertainty: The context handles uncertainty, often by using result tuples.

• Present a single, common API: The context provides a single access point for a family of services.

Based on what you’re doing in your code, the boundary may have other responsibilities as well. ...