AgentSkillsCN

phoenix-contexts

Phoenix 上下文模式、限界上下文设计、作用域划分以及模块结构。在设计上下文、梳理业务逻辑或规划模块架构时加载这些内容。

SKILL.md
--- frontmatter
name: phoenix-contexts
description: Phoenix context patterns, bounded context design, scopes, and module structure. Load when designing contexts, organizing business logic, or planning module structure.

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

code
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 excessive cross-context calls

Cross-Context References

elixir
# ✅ Reference by ID, convert at boundary
def create_order(%Scope{} = scope, user_id, product_ids) do
  with {:ok, user} <- Accounts.fetch_user(scope, user_id) do
    do_create_order(scope, user.id, product_ids)
  end
end

# ❌ Reaching into other context's internals
alias MyApp.Accounts.User  # Don't do this
Repo.all(from o in Order, join: u in User, ...)  # Don't query other schemas

Anti-patterns

WrongRight
Service objects (UserCreationService)Context functions (Accounts.create_user/2)
Repository pattern wrapping RepoRepo IS the repository
Direct Repo calls in controllersDelegate to context
Schema callbacks with side effectsUse Ecto.Multi

Version Notes

  • Phoenix 1.8+: Uses built-in %Scope{} struct for authorization context
  • Phoenix 1.7: Requires manual authorization context (see references/scopes-auth.md "Pre-Scopes Patterns")

References

For detailed patterns, see:

  • references/context-patterns.md - Full context module, PubSub, Multi, cross-boundary
  • references/scopes-auth.md - Scope struct, multi-tenant, authorization, plugs
  • references/routing-patterns.md - Verified routes, pipelines, API auth
  • references/plug-patterns.md - Function/module plugs, placement, guards
  • references/json-api-patterns.md - JSON controllers, FallbackController, API auth