菜单
Explains how Forze resolves dependencies in applications: plain vs routed Deps, route=spec.name, built-in DepsModule composition, and merge conflicts. Use when debugging handler resolution or wiring Postgres, Redis, S3, and other shipped integration modules.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Uses Forze queue, pub/sub, and stream contracts with QueueSpec, PubSubSpec, StreamSpec, SQSDepsModule, RabbitMQDepsModule, Redis adapters, and Mock adapters. Use when producing, consuming, or testing async messages/events.
Implements Forze document and search access the kit-first way: DocumentFacade and SearchFacade over build_document_registry / build_search_registry, kit DTOs (DocumentIdDTO, ListRequestDTO, DocumentUpdateDTO), the query DSL, pagination, cache-aware DocumentSpec / SearchSpec, and the Postgres / Mongo / Firestore / Meilisearch backends behind them. Use when building data access features.
Optimize code only after a real, measured performance problem - distinguish macro (design-level) from micro (fine-tuned) performance, reach for data-structure and algorithm wins before micro-tweaks, profile to find real hotspots, and don't trade readability or adaptability for unmeasured speed. Use when optimizing code, reviewing performance suggestions, choosing "faster" constructs, or when the user mentions performance, optimization, speed, or efficiency.
Name variables, functions, classes, and modules well by avoiding known anti-patterns - single letters, abbreviations, types baked into names, missing units, "Base"/"Abstract" class names, and "Utils"/"Helper" grab-bags. Use when naming or renaming code, reviewing names in a diff, or when the user mentions naming, identifiers, variable names, readability, or that a name feels off.
Keep code flat and readable by limiting indentation depth, using guard clauses with early returns, and extracting nested blocks into well-named functions. Use when writing or refactoring code with deep nesting, pyramid-shaped if/else, arrow code, or when the user mentions nesting, indentation, guard clauses, early returns, extracting functions, cyclomatic complexity, or making code more readable.
Make code explain itself instead of relying on comments - name sub-expressions, extract complex conditions into well-named functions, lean on the type system, and reserve comments for the "why" the code cannot express. Use when writing or reviewing comments, refactoring hard-to-read logic, deciding whether a comment is needed, or when the user mentions comments, self-documenting code, or code readability.
| name | forze-deps-consumption |
| description | Explains how Forze resolves dependencies in applications: plain vs routed Deps, route=spec.name, built-in DepsModule composition, and merge conflicts. Use when debugging handler resolution or wiring Postgres, Redis, S3, and other shipped integration modules. |
Use when wiring or debugging how your application resolves ports from ExecutionContext. For bootstrap and DepsRegistry, see forze-wiring. For mapping logical spec names to integration configs, see forze-specs-infrastructure. For a private integration not covered by shipped forze_* packages, see forze-custom-deps.
Deps registers providers in two shapes:
| Mode | Shape | Use when |
|---|---|---|
Deps.plain({DepKey: value}) | one provider per key | shared clients, secrets, idempotency defaults |
Deps.routed({DepKey: {route: value}}) | one provider per key + route | specs resolved by spec.name |
Shipped modules such as PostgresDepsModule, S3DepsModule, and InngestDepsModule return merged Deps containers. Your app passes them to DepsRegistry.from_modules(...).
DocumentSpec, QueueSpec, …) with a stable name (prefer a shared StrEnum).name to physical config (table, bucket, queue URL, …).ExecutionContext resolves the factory with route=spec.name, then builds the port.Convenience helpers (ctx.document.query, ctx.storage, …) do this internally. For other dep keys:
port = ctx.deps.resolve_configurable(
ctx, QueueCommandDepKey, order_queue, route=order_queue.name
)
Deps.merge(...) raises CoreException on duplicate plain keys, plain-vs-routed conflicts, or duplicate routed keys. Treat that as a wiring bug: two modules registered the same key/route, or you merged overlapping maps twice.
Built-in DepsModule.__call__ should only register providers. Connection pools and clients start via LifecycleModule or LifecycleStep factories on your LifecyclePlan (PostgresLifecycleModule, postgres_lifecycle_step, s3_lifecycle_step, …). Keep deps and lifecycle as separate plans, freeze both, then pass the frozen registries to ExecutionRuntime. See forze-wiring.
ExecutionContext.name and deps-module route keys — use one shared StrEnum for both.resolve_configurable without route=spec.name for spec-backed keys.Docs are versioned. These links use
latest(the newest release). If your app pins an olderforzeminor, replacelatestin the URL with that version (e.g..../forze/0.3/...) or use the version selector on the site.