phoenix-contexts

# Phoenix Contexts Reference Reference for designing and implementing Phoenix contexts (bounded contexts). ## Iron Laws — Never Violate These 1. **CONTEXTS OWN THEIR DATA** — Never query another context's schema directly via Repo 2. **SCOPES ARE MANDATORY (Phoenix 1.8+)** — Every context function MUST accept scope as first parameter 3. **THIN CONTROLLERS/LIVEVIEWS** — Controllers translate HTTP, business logic stays in contexts 4. **NO SIDE EFFECTS IN SCHEMAS** — Use `Ecto.Multi` for transactions with side effects ## Context Structure ``` lib/my_app/ ├── accounts/ # Context directory │ ├── user.ex # Schema │ ├── scope.ex # Scope struct (Phoenix 1.8+) ├── accounts.ex # Context module (public API) ``` ## Phoenix 1.8+ Scopes (CRITICAL) All context functions MUST accept scope as first parameter: ```elixir def list_posts(%Scope{} = scope) do from(p in Post, where: p.user_id == ^scope.user.id) |> Repo.all() end def create_post(%Scope{} = scope, attrs) do %Post{user_id: scope.user.id} |> Post.changeset(attrs) |> Repo.insert() |> broadcast(scope, :created) end ``` ## Quick Decisions ### When to SPLIT contexts? - Module exceeds ~400 lines - Functions don't share domain language - Could theoretically be a separate microservice - Team member could own it independently ### When to KEEP together? - Resources share vocabulary and domain concepts - Functions frequently operate on same data together - Splitting would create exces...