Module Architecture

MMO-DEV WEB separates core cabinet features from optional add-ons. Warehouse and the partner program are part of the core cabinet and require no purchase. Shop, marketplace, cases, support, promo games, and other extensions are enabled separately.

System Layers

Layer	Role
SaaS panel	Stores project, server, payment, and module settings
Public API	Returns data and performs operations through /graphql
Client site	Displays pages, player cabinet, and user scenarios
Templates	Control markup, blocks, text, and data output
Game infrastructure	Handles game accounts, characters, warehouse, and server actions

Module Lifecycle

This lifecycle applies to optional add-ons. The core warehouse becomes available after a game server is connected.

1. The module is enabled or purchased in the panel.
2. Required project settings are enabled.
3. The client site receives data through the API.
4. Templates render module blocks and forms.
5. The user performs an action.
6. The API returns a result or an error.

Responsibility Boundaries

Settings, access rights, and business rules should stay in the panel and API. Templates should not duplicate logic for prices, permissions, bonuses, server availability, or payment conditions.

A template is responsible for presentation: showing data, state, warning, button, or form. The API should decide whether an operation is allowed.

Module Dependencies

Some modules depend on shared settings:

• payment modules require a payment system and currency;
• the core warehouse and game add-ons require a connected game server;
• marketplace depends on game accounts, characters, or items;
• support and notifications depend on email, Telegram, or other communication channels.

Designing Changes

Before changing a module, define:

• what settings are needed in the panel;
• what data the template needs;
• what API operation performs the action;
• what errors should be shown to the user;
• how the scenario behaves without authorization;
• how it looks on mobile.