Skip to content

⚠️ Economy — Internal — Services

🎯 Purpose

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

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

These types are not entry points and are not extension points. They provide the built-in implementation of the public abstractions and may change over time.

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 documentation lives in:

  • Runtime/Systems/Economy/Services/index.md

🚫 Not for Production Use

Types in this folder are internal implementation details.

They should not be referenced from gameplay code or relied upon as stable APIs.

🧩 What Lives Here

This folder contains internal implementations of:

  • IShopService
  • ICraftingService
  • IRewardService

Each service:

  • Applies operation ordering and rollback behaviour as implemented by the built-in services
  • Coordinates between IValueLedger (money) and IItemStore (items)
  • Handles partial failure and may attempt rollback where possible
  • Produces EcoOpResult outcomes describing success or failure

🧠 Usage Guidance

Responsibilities

Internal services are responsible for:

  • Validation Input validation and early failure with clear EcoOpCode values

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

  • Execution Applies mutation ordering (money vs items) May attempt rollback on partial failure

  • Telemetry Passing sourceId to currency operations Recording canonical EcoReasons for operations

⚠️ Important Notes

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 are not intended to 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 or composition level

⚠️ Important Notes

Maintenance rules

  • Keep all service types internal and sealed
  • Do not expose service concrete types in public signatures
  • Do not add public helpers or convenience methods here
  • Changes should preserve the intended operation ordering and rollback behaviour of the built-in services

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

  • Economy — Abstractions
  • Economy — Facade
  • Economy — Adapters
  • Economy — Diagnostics