# Creating Modules

A module groups related functionality behind a boundary. The framework module contracts and boot lifecycle are described in Module Lifecycle. DBM Platform may add installer-specific manifests and lifecycle operations; those are platform behavior, not universal framework requirements.

# Suggested organization

modules/YourModule/
├── module.json
├── YourModule.php
├── Controller/
├── Service/
└── templates/

A platform installer may use a manifest like this:

{
  "name": "Your Module",
  "description": "A short description",
  "version": "1.0.0",
  "key": "your-module",
  "type": "plugin",
  "class": "Mod\\YourModule\\YourModule"
}

The exact manifest schema, discovery, install/enable/disable operations, and file-copy behavior depend on the platform installer and its lifecycle manager. Verify these against the target platform before publishing a module. Do not assume every framework application scans modules/ or uses this manifest.

Implement the module interface supported by the installed framework version. Register services through the module registration hook and initialize runtime behavior during boot. Keep dependencies explicit and avoid using another module's internal classes directly.

# Good practices

• Choose a unique, stable module key and provide a version.
• Declare dependencies and required configuration.
• Make optional integrations fail with clear configuration errors.
• Make install/uninstall operations safe to repeat where practical.
• Check whether an optional module is enabled before using it.