Visualisasi struktur rangka utama BIMA

Saya membaginya menjadi 4 diagram visual: Arsitektur Lapisan, Alur Permintaan (Request Flow), Pemisahan Mode (Normal vs Rescue), dan Siklus Plug-and-Play Modul.

1. Diagram Arsitektur Lapisan (Layered Architecture)

Ini adalah peta besar. Inti aplikasi (Kernel & Core Services) berada di tengah, mengisolasi dunia luar (Client) dari modul bisnis, dan mengisolasi modul bisnis dari database.

================================================================================
BIMA ARCHITECTURE OVERVIEW
================================================================================

[ 1. CLIENT / PRESENTATION LAYER ]
Web Browser (UI Shell) | API Consumers (ERP/HRIS/Accurate) | CLI / Cron
| | |
================================================================================
[ 2. GATEWAY & BOOTSTRAP LAYER (Pintu Masuk) ]
+----------------------------------------------------------------------------+
| • Entry Point (index.php) |
| • Environment Loader (Env Vars -> Config File -> Rescue Store) |
| • Mode Detector [ NORMAL MODE ] <=====================> [ RESCUE MODE ] |
| • Global Middleware (CSRF, Session, Rate Limit) |
| • Router & Dispatcher |
+----------------------------------------------------------------------------+
| |
================================================================================
[ 3. CORE SERVICES LAYER (Layanan Pusat / "Pemerintah") ]
+--------------------+ +--------------------+ +---------------------------+
| Access Control | | Workflow Engine | | Database Manager |
| (RBAC + Scope + | | (Approval, Verify, | | (Connection, Migration, |
| Policy Eval) | | Reject, Delegate) | | Backup, Test 6-Levels) |
+--------------------+ +--------------------+ +---------------------------+
+--------------------+ +--------------------+ +---------------------------+
| Module Registry | | Audit & Logging | | Notification & Events |
| (Manifest Parser, | | (Immutable Trail, | | (Queue, Dispatch, Hooks) |
| Contract Enforcer)| | Access Deny Log) | | |
+--------------------+ +--------------------+ +---------------------------+
| |
================================================================================
[ 4. MODULE ENGINE & CONTRACT LAYER (Penjaga Gerbang Modul) ]
+----------------------------------------------------------------------------+
| 1. Manifest Validator 2. Dependency Checker 3. Route/Perm Binder |
| 4. Lifecycle Hooks (Install/Upgrade/Disable/Uninstall) |
| Batas Keras: Modul tidak bisa bypass lapisan ini. |
+----------------------------------------------------------------------------+
| |
================================================================================
[ 5. BUSINESS MODULES LAYER (Modul Bisnis / "Penduduk") ]
+--------------+ +--------------+ +--------------+ +--------------+
| maintenance | | qc-inspect | | logistics | | [New Module] |
| (Work Order) | | (Checklist) | | (Surat Jalan)| | (Custom) |
+--------------+ +--------------+ +--------------+ +--------------+
(Setiap modul terisolasi: Controllers, Services, Repos, Views, Migrations)
| |
================================================================================
[ 6. DATA & INFRASTRUCTURE LAYER (Penyimpanan) ]
+--------------------+ +--------------------+ +---------------------------+
| MySQL / MariaDB | | Local File Store | | Rescue Store (Local) |
| (App Data, Audit, | | (Assets, Cache, | | (Encrypted Config, Rescue |
| Module Tables) | | Logs, Exports) | | Auth, Emergency Queue) |
+--------------------+ +--------------------+ +---------------------------+

2. Alur Permintaan (Request Flow)

Diagram ini menunjukkan bagaimana satu permintaan pengguna diproses. Perhatikan bagaimana RBAC, Scope, dan Workflow bekerja berurutan sebelum logika bisnis dieksekusi.

[User] -> [Request: POST /maintenance/work-order/123/approve]
|
v
[Bootstrap] -> Cek Mode (Normal?) -> Cek Sesi (Login?)
|
v
[Router] -> Identifikasi Modul: maintenance, Aksi: approve, ID: 123
|
v
[Module Engine] -> Apakah modul maintenance Aktif?
| (Tidak) -> [Tolak: Modul tidak aktif]
| (Ya)
v
[Core: RBAC] -> Apakah User punya izin maintenance.work-order.approve?
| (Tidak) -> [Tolak: Forbidden] + [Audit: Access Denied]
| (Ya)
v
[Core: Scope] -> Apakah User punya akses ke Plant/Divisi milik WO #123?
| (Tidak) -> [Tolak: Data Scope Exceeded]
| (Ya)
v
[Core: Workflow] -> Cek Status Dokumen & Kebijakan Approval:
| 1. Apakah status dokumen = 'pending_approval'?
| 2. Apakah User BUKAN pembuat dokumen (Maker-Checker)?
| 3. Apakah nominal <= limit approval User?
| (Gagal salah satu) -> [Tolak: Workflow Policy Violation]
| (Lulus)
v
[Module Service] -> Eksekusi Logika Bisnis (Update status, kirim notifikasi)
|
v
[Core: Audit] -> Catat: Siapa, Kapan, Dari mana, Apa yang diubah (Before/After)
|
v
[Response] -> Kembali ke UI / API Consumer

Pemisahan Mode: Normal vs Rescue

Ini adalah visualisasi bagaimana BIMA menangani kondisi database mati atau saat pertama kali diinstal, tanpa mengorbankan keamanan.

+-------------------------+
| BOOTSTRAP DETECTOR |
+-------------------------+
|
+----------------+----------------+
| |
[DB Config Exists & OK?] [DB Config Missing / Failed]
| |
v v
+---------------------+ +-------------------------+
| NORMAL MODE | | RESCUE MODE |
+---------------------+ +-------------------------+
| • Koneksi DB: ON | | • Koneksi DB: OFF |
| • Autentikasi: DB | | • Autentikasi: LOCAL |
| • Modul Bisnis: ON | | • Modul Bisnis: BLOCKED |
| • RBAC Penuh: ON | | • RBAC: BYPASSED |
| • UI: Normal | | • UI: Banner "RESCUE" |
+---------------------+ +-------------------------+
| |
[FITUR YANG BISA DIAKSES] [FITUR YANG BISA DIAKSES]
• Semua Modul Bisnis • Setup / Ubah Koneksi DB
• Manajemen User & Role • Uji Koneksi DB (6 Level)
• Pengaturan Aplikasi • Import/Export Config
• Laporan & Audit • Repair Registry Modul
• Backup/Restore DB
• Log Audit Darurat (Lokal)

4. Siklus Plug-and-Play Modul

Diagram ini menjelaskan bagaimana modul baru "ditemukan" dan "diikat" ke sistem utama tanpa mengubah satu baris kode di Kernel.

[Developer] menaruh folder modul baru di /bima_modules/qc-inspection/
|
v
[Kernel: Module Registry] melakukan pemindaian (scan)
|
v
[Baca Manifest] -> qc-inspection/manifest.json
| (Gagal validasi) -> [Karantina: Log error, jangan muat]
| (Lulus)
v
[Registry Sync] -> Mendaftarkan metadata ke Database Inti:
| 1. Tambahkan entri di tabel bima_modules (Status: Pending Install)
| 2. Ekstrak Menu Tree -> Masukkan ke bima_menus
| 3. Ekstrak Permissions -> Masukkan ke bima_permissions (Status: Unassigned)
| 4. Ekstrak Workflows -> Masukkan ke bima_workflows
|
v
[Admin Dashboard] -> Muncul notifikasi: "Modul baru ditemukan: QC Inspection"
|
v
[Admin] melakukan "Dry Run" (Simulasi Instalasi)
| -> Sistem menampilkan: Tabel apa yang akan dibuat, Menu apa yang muncul,
| Izin apa yang tersedia (belum ada yang dicentang).
|
v
[Admin] klik "Install & Activate"
|
v
[Module Engine] menjalankan Migration modul -> Membuat tabel bima_mod_qc_*
|
v
[Selesai] -> Modul aktif. Menu muncul di UI Shell.
-> Admin RBAC sekarang bisa memberikan izin qc.* ke Role yang sesuai.

Poin Kunci Visualisasi untuk Native PHP:

• Tidak ada "Magic Routing": Router di Lapisan 2 secara eksplisit membaca registry dari database/cache. Jika modul tidak ada di registry, router tidak akan melewatkan permintaan ke folder modul tersebut.
• Prefix Tabel yang Ketat: Di Lapisan 6, terlihat jelas bahwa modul menggunakan prefix bima_mod_{code}_. Ini mencegah bentrok nama tabel antar modul dan memudahkan backup/restore per modul.
• Rescue Store Terpisah: Di Lapisan 6, Rescue Store adalah folder/file lokal (bisa SQLite kecil atau file JSON terenkripsi) yang menyimpan kredensial rescue dan konfigurasi. Ini memastikan aplikasi tidak "buta" saat MySQL mati.
• Core Services sebagai "Satu Pintu": Modul bisnis (Lapisan 5) tidak diizinkan memanggil langsung ke tabel user atau tabel log. Mereka harus memanggil Access Control atau Audit di Lapisan 3.