Docs
RU

Module runtime

uticms.modules.runtime · verified 2026-07-17

Overview

Scope
Filesystem modules under modules/ and their runtime lifecycle within Kernel / Domain / Extension layering

Key concepts

Kernel
UTICMS platform in app/ and bootstrap/; not installable business code.
Core Module
Manifest with is_core true; applies product core updates to Kernel and exposes core_version.
Domain Module
Standalone business domain; meaningful without Extension modules.
Extension Module
Adds capability on top of one or more Domain modules via public extension points.
Manifest
module.json metadata declaring namespace, providers, routes, migrations, seeders, and optional integrations.
Module Path
Database path value in the canonical form modules/<ModuleName>.
Install Wizard
Staged module installation flow for manifests declaring install support.
Module Discovery
Runtime check such as isModule() for optional behavior; not an architectural dependency.
Architectural Dependency
Use of another module's internal services, models, classes, config, or localization outside its public API.
Id Marketplace
Opt-in manifest field for marketplace entitlement; maps to JWT product codes such as module:<Name>.

Structure

  • Kernel
    • Codeapp/
    • Bootstrapbootstrap/
  • Architecture Layers
    • KernelPlatform in app/ and bootstrap/
    • Domain ModuleSelf-contained business package under modules/<DomainModule>/
    • Extension ModuleDependent package under modules/<ExtensionModule>/ that extends one or more Domain modules
  • Registry
    • Databasemodules table; app/Models/Module.php
    • Manifestsmodules/<ModuleName>/module.json
  • Runtime Services
    • Discoveryapp/Services/ModuleAutoDiscoveryService.php
    • Installerapp/Services/ModuleInstallerService.php
    • Bootstrapapp/Services/Modules/ModuleRuntimeBootstrap.php
    • Viewsapp/Services/Modules/ModuleViewLoader.php
    • Assetsapp/Services/Modules/ModuleAssetLoader.php
    • Entitlementapp/Services/Modules/ModuleEntitlementGuard.php
  • Cross Module Mechanisms
    • Contracts
    • Events
    • Pipelines
    • Bridge
    • Public_API
    • Extension_Points

Facts

  • AppServiceProvider asks ModuleAutoDiscoveryService for providers and registers them during application boot. authoritative
  • Installed module records store name, slug, version, is_active, priority, path, namespace, env, and installed_at. authoritative
  • ModuleInstallerService runs module migrations and declared seeders, creates or updates the module record, activates when requested, persists schema state, clears integration caches, and publishes assets for active installs. authoritative
  • Wizard preparation verifies manifest dependencies before preparing the database and record; finalization activates, runs seeders, publishes assets, persists state, and refreshes caches. authoritative
  • Published module assets are copied to public/module/<slug>; the module_asset route is a dynamic fallback. authoritative
  • A manifest with is_core true reports kernel version for heartbeat and applies product core patch or full updates to Kernel files. authoritative
  • A Domain module encapsulates a business area and may use Kernel services without depending on Extension modules built on top of it. authoritative
  • An Extension module lists Domain module dependencies in module.json and integrates through public extension mechanisms. authoritative
  • A module may call isModule() to adapt optional behavior without forming an architectural dependency on another module's internals. authoritative
  • Modules integrate through Contracts, Events, Pipelines, Bridge adapters, public module APIs, and manifest or provider extension points. authoritative

How-to guides

Install Module

  1. parse module.json and validate required dependencies
  2. run ModuleInstallerService::install or the wizard preparation/finalization lifecycle
  3. verify migrations, seeders, module record, active state, and published assets
  4. clear or rebuild module integration caches

Add Extension Module

  1. declare required Domain modules in module.json dependencies.required
  2. integrate only through public contracts, events, pipelines, bridge, or extension points
  3. verify Domain modules do not import the new Extension internals

Rules

Architectural rule

Do not treat a module folder as permission to use its public runtime integration; active-module eligibility controls runtime use.

Architectural rule

Store module paths consistently as modules/<ModuleName>; do not mix bare folder names with this form.

Examples

Layer Domain

Shop and Blog are Domain modules in this repository.

Layer Extension

ShopB2C requires Shop and adds a storefront layout; OneCBridge requires Shop and exposes integration API routes.

Dependency Manifest

Example only; Extension modules declare Domain dependencies by manifest name.

{
  "name": "ShopB2C",
  "dependencies": { "required": { "Shop": "^1.0" } }
}

modules/ShopB2C/module.json