Skip to content

🔗 Currency — Integrations

Namespace: varies by integration

This folder contains optional integration layers that connect the Currency system to other RevFramework systems.

Integrations allow Currency to operate on external data sources or behaviours without introducing hard dependencies into the core system.

🎯 Purpose

  • Provide clean integration seams between Currency and other systems
  • Keep Currency decoupled and modular
  • Allow other systems to act as currency sources, sinks, or backends
  • Ensure all integrations are optional and removable

Currency itself does not require any integration to function.

🧩 Folder Layout

Integrations/
  Currency/
    Inventory/    // Inventory-backed currency integration

Each subfolder represents a specific system integration.

🧠 Mental Model

[ RevFramework System (e.g. Inventory) ]
                ↓
        [ Integration Layer ]
                ↓
        [ ICurrencyService ]
                ↓
        [ Currency System ]

Integrations translate external data and behaviour into the Currency service surface.

Currency itself remains unaware of the external system.

⚙️ How Integrations Work

  • Integrations expose functionality through factory helpers
  • They return ICurrencyService implementations
  • Concrete adapter types remain internal
  • All interaction still happens via the Currency public API

Example (Inventory):

#if REV_INVENTORY_PRESENT
var svc = CurrencyInventoryFactories.InventoryBacked(
    inventoryService,
    coinItemDefinition,
    "Backpack"
);
#endif

These integrations are designed for RevFramework systems. They are not intended as a universal integration layer for third-party solutions.

🔐 Optional by Design

All integrations are:

  • compile-time gated (e.g. REV_INVENTORY_PRESENT)
  • safe to remove
  • not required for Currency usage

If an integration is not present:

  • Currency continues to function normally
  • No runtime errors are introduced

⚠️ Behaviour Notes

  • Integrations depend partly on the connected system’s behaviour
  • Guarantees such as atomicity or transfer behaviour may vary
  • Currency decorators (caps, audit, escrow, authority, etc.) still apply normally

Integrations do not override or bypass Currency rules.

🚫 What Integrations Are NOT

Integrations do not:

  • Merge systems into a single unified model
  • Guarantee cross-system atomicity
  • Provide networking, persistence, or replication
  • Replace the connected system’s logic

They are bridges, not system replacements.

💡 When to Use Integrations

Use integrations when:

  • You want to reuse existing RevFramework systems (e.g. Inventory) as a currency backend
  • You want Currency features (caps, audit, escrow, etc.) applied to external data
  • You need a clean boundary between systems without tight coupling

🌍 Third-Party / Custom System Use

These integrations are built and supported for RevFramework systems only.

If you are connecting Currency to non-RevFramework systems:

  • Treat these integrations as reference examples only
  • Implement your own adapter or factory
  • Use the public ICurrencyService interface

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

🧹 Safe to Delete

If you are not using any integrations, this entire folder can be removed safely.

Currency will continue to work using:

  • SceneCurrencyService
  • or your own ICurrencyService implementation
  • Currency Core — service composition and decorators
  • Adapters — implementation details for specific integrations
  • Connected systems — Inventory, Pickups, or other RevFramework modules

🥃 Rab verdict

This layer is doing exactly what it should:

👉 clean seams 👉 no hard dependencies 👉 optional by design 👉 adapters hidden behind factories

That’s proper integration architecture 👍