Skip to content

Economy – Internal – Services

⚠️ Internal orchestration layer – not supported public API

Namespace root: RevGaming.RevFramework.Economy.Internal.Services
Folder: Runtime/Systems/Economy/Internal/Services/

This folder contains the internal service implementations that orchestrate multi-step economy operations such as Shop, Crafting, and Rewards.

These types are not entry points and are not extension points. They exist to implement the behaviour promised by the public abstractions and may change without notice.

If you are looking for how to use Economy, start with: - RevGaming.RevFramework.Economy.Abstractions (interfaces) - EconomyBootstrap (facade wiring) - RevGaming.RevFramework.Economy (model + results + reasons)

Public-facing behaviour docs live here: - Runtime/Systems/Economy/Services/index.md

What lives here

This folder contains internal implementations of:

  • IShopService
  • ICraftingService
  • IRewardService

Each service: - Enforces the documented operation semantics (ordering, rollback rules) - Coordinates between: - IValueLedger (money) - IItemStore (items) - Handles partial failure and rollback deterministically - Produces stable EcoOpResult outcomes

Responsibilities

Internal services are responsible for:

  • Validation

  • Input validation and early failure with clear EcoOpCode values

  • Preflight

  • Best-effort UX checks (CanPay, ownership, capacity)

  • Never authoritative

  • Execution

  • Authoritative mutation ordering (money vs items)

  • Deterministic rollback on partial failure

  • Telemetry

  • Propagating sourceId on currency operations
  • Recording canonical EcoReasons for all operations

What services are not

  • They are not public APIs
  • They are not intended for direct invocation
  • They are not designed for subclassing or extension
  • They should not be referenced from gameplay, UI, or networking code

Custom behaviour should be introduced by: - Supplying custom implementations of the public abstractions, or - Modifying behaviour at the facade / composition level

Maintenance rules (for future-us)

  • Keep all service types internal and sealed
  • Never expose service concrete types in public signatures
  • Do not add public helpers or convenience methods here
  • Any change must preserve documented semantics and rollback guarantees

If a change cannot be made without breaking these rules, it belongs in a new abstraction — not here.