project structure

introduction

dframework enforces a deterministic application layout. you cannot configure or modify the default directory structure. this rigidity ensures that every application built with the framework is instantly familiar to any developer and that the internal engine can optimize loading and compilation paths aggressively.

the root directories

the config directory

the config directory holds all of your configuration files. the primary file is the application configuration where you define environment settings session drivers and security behaviors.

1// config/app.js
2import { Env } from 'dframework';
3export default {
4  name: Env.value('APP_NAME', 'dframework'),
5  env: Env.value('APP_ENV', 'production'),
6  debug: Env.value('APP_DEBUG', false),
7  url: Env.value('APP_URL', 'http://localhost'),
8  port: Env.value('APP_PORT', 825),
9  locale: Env.value('APP_LOCALE', 'en'),
10  key: Env.value('APP_KEY'),
11  antiPeeping: Env.value('ANTI_PEEPING', false),
12  shield: Env.value('SHIELD_ENABLED', false),
13  session_driver: Env.value('SESSION_DRIVER', 'memory'),
14  queue: {
15    maxWorkers: Env.value('QUEUE_MAX_WORKERS', 4),
16  },
17  database: {
18    host: Env.value('DB_HOST', 'localhost'),
19    user: Env.value('DB_USER', 'root'),
20    pass: Env.value('DB_PASS', ''),
21    name: Env.value('DB_NAME', 'dframework'),
22  },
23  storage: {
24    disks: {
25      local: {
26        root: Env.value('STORAGE_ROOT', './storage'),
27      },
28      public: {
29        root: Env.value('STORAGE_PUBLIC', './storage/public'),
30      },
31      secure: {
32        root: './storage/secure',
33        encryptionKey: Env.value('APP_KEY'),
34      },
35    },
36  }
37};

1// config/native.js
2export default {
3  name: null,
4  identifier: 'com.dframework.app',
5  version: '1.0.0',
6  build: 1,
7  icon: { source: 'native/assets/icon.png', background: '#ffffff', padding: 0 },
8  splash: { enabled: true, background: '#0a0a0a', icon: 'native/assets/icon.png', iconSize: 0.3, fadeOut: 300 },
9  theme: { statusBar: 'dark', primary: '#d3ac5f', background: '#0a0a0a', navigationBar: '#0a0a0a', safeArea: true },
10  ios: { orientation: 'all', statusBarHidden: false },
11  android: { orientation: 'unspecified', minSdk: 24, targetSdk: 34, permissions: ['INTERNET'] },
12  desktop: { width: 1280, height: 720, resizable: true, minWidth: 800, minHeight: 600, titleBarStyle: 'default' },
13};

the console directory

background tasks and scheduling definitions are located in the console directory. the framework looks specifically for the schedule definition file here to configure recurring jobs and background workers. custom commands are also registered here.

1// console/Schedule.js
2export default function (scheduler) {
3  scheduler.command('CleanupExpiredSessions').daily();
4}

the controllers directory

the controllers directory contains the classes that handle your incoming request logic. controllers organize your behavior into simple async methods that are invoked automatically by the router. there is no base controller class to extend. arguments like the request and response objects are entirely optional if your logic does not require them.

1// controllers/IndexController.js
2export default class IndexController {
3  async index() {
4    return render('index');
5  }
6}

the database directory

the database directory holds all of your database related files including your migrations and seeders. the framework utilizes this directory when executing schema building commands allowing you to track database changes across environments.

1// database/migrations/0001_create_users_table.js
2export async function up() {
3  await Schema.create('users', table => {
4    table.increments();
5    table.string('email').unique();
6    table.string('password');
7    table.timestamps();
8  });
9}
10 
11export async function down() {
12  await Schema.dropIfExists('users');
13}

1// database/seeders/DatabaseSeeder.js
2export async function run() {
3  await table('users').insert({
4    email: 'admin@example.com',
5    password: 'password' // passwords are automatically hashed
6  });
7}

the lang directory

localization strings and translation dictionaries are stored in the lang directory. these are typically stored as json files inside locale specific folders. the framework automatically loads these files to provide multilingual support across your application and view templates.

1// lang/en/common.json
2{
3  "welcome": "welcome to dframework",
4  "login": "log in to your account"
5}

the middleware directory

the middleware directory contains classes that filter and inspect http requests entering your application. you define custom logic here to enforce authentication rate limiting and request manipulation before it reaches your controllers.

1// middleware/EnsureAuth.js
2export default class EnsureAuth {
3  handle(req, next) {
4    if (!Auth.check()) return abort(401);
5    return next(req);
6  }
7}

the models directory

your active record entities reside in the models directory. the framework relies on this exact location to dynamically resolve models particularly during authentication flows and implicit route model binding. models represent the single source of truth for your database schema abstractions.

1// models/User.js
2export default class User extends Model {
3  // model definition
4}

the native directory

the native directory contains code specifically required for integrating the web application into native mobile and desktop environments. the framework handles native compilation and asset injection utilizing this directory to bridge web views with native device capabilities.

the public directory

static assets and public facing files belong in the public directory. the internal web server is capable of serving these files directly during local development. in production environments this directory acts as the root for your web server configuration.

the routes directory

the routes directory is the entry point for all incoming requests. the framework automatically reads and registers all routing definitions found within this folder. you define your web endpoints and application logic mappings here. there is no need to manually import these files elsewhere as the framework handles discovery during the boot process.

1// routes/web.js
2Route.get('/', 'HomeController@index');

the storage directory

the storage directory is reserved for application generated files. this includes cached views temporary hot reloading data and user uploaded content. the framework automatically manages the internal structure of this directory and maintains a public symbolic link for accessible uploads.

the views directory

the views directory contains all frontend templates. the internal view compiler statically analyzes and optimizes these templates during the production build pipeline. you cannot place templates outside this directory as the compilation engine specifically targets this path.

1<!-- views/welcome.blade -->
2@extends('layouts.app')
3 
4@section('content')
5  <div>welcome to dframework</div>
6@endsection