Skip to content

🔌 Inventory ↔ Currency Integration

This folder contains the optional integration layer between Inventory and Currency.

It allows Inventory-driven workflows to interact with Currency without creating a hard dependency between the two systems.

This integration is built and supported for RevFramework systems only. It is not intended as a general integration layer for third-party inventory or currency solutions.

🎯 Purpose

The Currency Integration exists to:

  • enable currency-aware item interactions
  • bridge Inventory operations with Currency services
  • keep both systems decoupled and optional

Inventory does not depend on Currency. Currency does not depend on Inventory.

This layer connects them only when both are present.

🧠 Core Idea

Inventory owns items. Currency owns value. Integration coordinates between them.

This means:

  • Inventory never mutates currency directly
  • Currency never accesses inventory directly
  • Integration translates between the two

🔄 Typical Flow

A currency-aware inventory operation looks like:

Inventory Intent
      ↓
Integration Layer
      ↓
Currency Service (ICurrencyService)
      ↓
Result (CurOpResult)
      ↓
Inventory continues or fails

🧩 What Lives Here

This folder typically contains:

  • Currency-aware helpers or adapters
  • Result translation (e.g. CurOpResult handling)
  • Bridge logic between item usage and currency mutation

It does not contain:

  • core inventory logic
  • core currency logic
  • UI or presentation systems
  • gameplay rules

🔗 When This Is Used

This integration is used when:

  • items cost currency
  • items grant currency
  • inventory actions depend on currency state

Examples:

  • buying items via inventory
  • consuming items that grant money
  • gating item usage behind currency checks

⚠️ Important Boundaries

Inventory does not:

  • know about currency balances
  • enforce currency policy
  • mutate wallets directly

Currency does not:

  • know about inventory containers
  • manage item state
  • perform gameplay orchestration

Integration does:

  • call Currency services
  • translate results into inventory-safe behaviour
  • remain thin and predictable

🧱 Design Rules

Follow these rules when working in this layer:

  • Keep logic thin and explicit
  • Do not duplicate behaviour from Currency or Inventory
  • Do not introduce gameplay rules here
  • Do not build UI logic here
  • Always rely on public APIs from both systems

If logic becomes complex, it likely belongs in:

  • Currency (value rules, policies)
  • Inventory (item logic)
  • Economy (multi-step orchestration)

🧠 Mental Model

Think of this layer as:

A translator, not a system

It converts:

  • inventory intent → currency operation
  • currency result → inventory-safe outcome

Nothing more.

🧪 Missing System Behaviour

If Currency is not present:

  • this integration layer is unused
  • inventory continues to function normally
  • no currency operations occur

This is intentional.

🌍 Third-Party / Custom System Use

This integration is built for RevFramework Inventory and Currency systems only.

If you are integrating with non-RevFramework systems:

  • Treat this as a reference example
  • Implement your own bridge or adapter
  • Use the public APIs of each system

👉 Custom or third-party integrations are not supported by this layer.

  • Inventory → owns item state
  • Currency → owns value state
  • Economy → orchestrates complex multi-step transactions

✅ TL;DR

  • Optional bridge between Inventory and Currency
  • Keeps both systems decoupled
  • Translates intent and results
  • Contains no gameplay rules

If it feels like this layer is doing too much, it probably is.