PRD - ERP Internal Kantor
Kerangka platform all in one untuk operasional internal Nusa Tiga Putra. Semua modul bisnis dikembangkan sebagai aplikasi terpisah, terhubung ke satu database yang sama, dengan standar stack dan keamanan yang seragam.
Tidak ada hasil
Tidak ada bab yang cocok dengan kata kunci tersebut. Coba kata lain seperti “RBAC”, “MongoDB”, atau “Sub-program”.
Ringkasan #
Dokumen ini adalah skeleton PRD, bukan PRD fitur lengkap. Tujuannya mengunci fondasi supaya penambahan modul nanti tidak memicu rework arsitektur.
- Satu database MongoDB dipakai bersama semua modul
- Tujuh folder shared di root, mirror 1:1 di
/Dokumentasi - Dashboard gabungan sengaja ditunda sampai modul dasar solid
1. Tujuan #
1.1 Objektif
Membangun aplikasi kantor all in one untuk memenuhi kebutuhan operasional internal, bukan sekadar tools lepas. Satu platform yang menaungi seluruh proses kerja kantor, dari collection sampai project baru ke depan.
1.2 User profile dan role
Platform melayani 10 peran sebagai acuan awal RBAC dan SBAC di bab keamanan. Peran ini bukan daftar akhir, tapi titik mulai untuk desain akses.
| Role | Catatan cakupan |
|---|---|
| Direktur | Akses lintas modul, persetujuan strategis |
| HRD | Data kepegawaian, rekrutmen, penilaian |
| Manager Umum | Operasional harian dan koordinasi |
| Tech Lead IT | Arsitektur, review, standar kode |
| IT | Pengembangan dan pemeliharaan |
| Admin | Administrasi dan entri data |
| IT Support | Dukungan teknis dan operasional |
| Team Leader | Koordinasi tim collection |
| Deskcoll | Eksekusi collection harian |
| Vendor / Mitra | Akses terbatas berbasis scope, bukan role penuh |
1.3 Cakupan
Scope mencakup seluruh proses collection dan berpotensi menaungi project baru. Ada rencana multi tenant, tapi baru sebagai pertimbangan arsitektur, belum diimplementasi di fase awal.
1.4 Success metrics fase 1
Fase 1 dianggap berhasil kalau dua hal ini terpenuhi.
Pertama, skeleton (fondasi arsitektur, security, struktur /Sub-program) fungsional. Kedua, skeleton bisa connect dan terintegrasi dengan program terpisah yang sudah ada sebelumnya, bukan mulai dari nol.
1.5 Kebutuhan fungsional
Belum didefinisikan. Masih fase 1, fokus ke fondasi bukan fitur. Akan disusun di iterasi PRD berikutnya begitu modul mulai ditentukan.
Prinsip fondasi #
Setiap modul bisnis dikembangkan sebagai aplikasi terpisah, tapi dengan tiga ikatan yang tidak boleh dilanggar:
- Semua modul connect ke satu database yang sama (shared MongoDB)
- Semua modul pakai stack, standar keamanan, dan standar kode yang sama
- Semua modul ditaruh sebagai sub folder di dalam satu folder induk
/Sub-program
Prinsipnya, bangun fondasi yang kuat dan seragam dulu, supaya waktu modul ditambahkan satu per satu tidak ada rework arsitektur. Dashboard atau laporan gabungan dibangun paling akhir setelah modul dasar solid.
2. Tech stack #
| Layer | Pilihan |
|---|---|
| Frontend | React + Vite |
| Backend | NestJS |
| Komunikasi | REST API |
| Database | MongoDB (NoSQL, shared single database untuk semua modul) |
| Bahasa | JavaScript (konsisten front dan back) |
Karena NoSQL shared database, setiap modul wajib punya penamaan collection yang di namespace jelas (lihat bab keamanan §5.3) supaya tidak tabrakan schema antar modul.
3. Struktur folder #
Ini struktur root asli Z:\ERP NUSATIGAPUTRA, bukan skema hipotetis. Pola: 7 folder shared di root, dan /Dokumentasi mirror strukturnya 1:1. Sub-program belum dipecah per modul karena masih fase skeleton.
3.1 Batas pengerjaan per folder #
Setiap folder shared punya batas scope yang tegas. Modul di /Sub-program/<nama> tidak boleh membawa security, backend base, atau frontend base sendiri, semua import dari root.
| Folder | Isi | Batas pengerjaan |
|---|---|---|
/Api | Kontrak API bersama, routing atau gateway, definisi endpoint umum, versioning, OpenAPI spec | Hanya kontrak dan gateway lintas modul. Endpoint spesifik modul tetap di modul itu, bukan di sini. |
/Backend | Library NestJS bersama, base module, interceptor, guard umum, DTO atau util bersama | Hanya kode yang dipakai minimal 2 modul. Logic bisnis spesifik modul tidak boleh masuk sini. |
/Database | Koneksi MongoDB, schema atau model bersama, migration dan seed | Hanya schema dan koneksi tingkat platform. Collection spesifik modul didefinisikan di modulnya, tetap connect ke instance yang didefinisikan di sini. |
/Frontend | Library React + Vite bersama, termasuk komponen reusable (§4.2), theme, hook umum | Hanya UI kit dan util lintas modul. Halaman spesifik modul tetap di /Sub-program/<modul>. |
/Redis | Konfigurasi dan client caching bersama | Hanya setup koneksi dan strategi cache umum (key naming, TTL default). Key spesifik fitur didefinisikan oleh modul yang pakai. |
/Security | RBAC, SBAC, enkripsi payload atau response, rate limit, fingerprinting, IP identifier (§5) | Satu satunya sumber kebenaran untuk security. Modul tidak boleh implementasi ulang. |
/Sub-program | Folder induk modul bisnis, tiap modul adalah app terpisah yang mengonsumsi 6 folder shared | Modul bisnis belum ditentukan. Tidak boleh dobel implementasi apa yang sudah ada di shared. |
/Dokumentasi | Mirror 1:1 dari 7 folder di atas, dokumentasi per layer atau modul | Wajib update setiap ada perubahan struktural di folder pasangannya. Murni dokumentasi, bukan tempat kode. |
Aturan lintas folder
- Semua modul connect ke instance MongoDB yang sama, didefinisikan di
/Database - Dashboard atau laporan gabungan ditunda, belum ada folder khusus di tree final
- Setiap penambahan atau perubahan di 7 folder root wajib disertai update dokumentasi pasangannya di
/Dokumentasi/<nama-folder>
4. Kode dan komponen #
4.1 Batas ukuran file
Maksimal 300 baris per file modul. Jika service, controller, atau component mendekati limit, wajib dipecah (extract ke sub modul, sub service, atau hook terpisah), bukan dipaksa muat.
4.2 Reusable components
Struktur: /Sub-program/_shared/components/<NamaKomponen>/
| File | Fungsi |
|---|---|
index.tsx atau .jsx | Implementasi komponen |
<Nama>.styles.ts | Styling terpisah jika perlu |
<Nama>.test.tsx | Unit test komponen |
README.md opsional | Cara pakai props untuk komponen kompleks |
Prinsip: 1 komponen sama dengan 1 folder sama dengan 1 file modul utama. Tombol, input, modal, table, semua reusable dari sini, tidak ada re implementasi lokal di masing masing modul.
4.3 Clean code
- Ikuti aturan clean code standar: single responsibility per fungsi atau file, penamaan deskriptif, tanpa dead code, tanpa magic number
- Untuk UI atau UX, wajib rujuk
ANTISLOP.mddari repomiqdadbadjuber/anti-slopsebelum generate tampilan. File ini jadi filter kualitas desain (38 rules R-01 sampai R-38 plus Delivery Gate), bukan style guide, jadi tetap sesuai palet dan tema Apple style di §6 - Setup: taruh
ANTISLOP.mddi/docsatau/.agent, lalu diAGENTS.mdatauCLAUDE.mdcukup taruh satu baris pointer, tidak perlu di inject ke semua sesi
5. Keamanan #
Berlaku di _shared/security dan dipakai semua modul. Didefinisikan satu kali sebagai middleware atau guard NestJS yang di reuse tiap modul backend, bukan diimplementasikan ulang per modul.
| Aspek | Implementasi |
|---|---|
| Access control | RBAC plus SBAC berlapis. Role menentukan kelas akses, SBAC menentukan cakupan data spesifik (misal per departemen atau per cabang) |
| Kriptografi | Enkripsi payload request dan response, bukan cuma transport TLS, tapi payload level encryption |
| Obfuscation | Response dan error message tidak boleh bocorkan struktur internal (stack trace, nama field DB asli) |
| Behavioral detection | Deteksi pola akses anomali (request pattern tidak wajar, brute force pelan) |
| Rate limiting | Per user dan per IP, di level gateway atau NestJS middleware |
| Caching | Layer cache (misal Redis) untuk kurangi beban DB dan response time, dengan invalidasi yang jelas per collection |
| Fingerprinting | Device atau browser fingerprint disimpan per sesi login, dipakai untuk deteksi session hijacking |
| IP identifier | Logging dan binding IP per sesi, alert kalau sesi pindah IP drastis |
hr_employees, coll_cases, bukan users generik yang dipakai dua modul.
6. Desain dan tema #
- Font: clean sans serif terinspirasi gaya Apple (kandidat Inter, General Sans, atau Geist), bukan font Apple asli San Francisco yang berlisensi, tapi karakter serupa yaitu rounded, netral, mudah dibaca
- Light mode: terang, whitespace lega, kontras lembut ala Apple standar
- Dark mode: gelap pekat dengan aksen material seperti Apple Pro Display, bukan dark mode abu abu datar, ada depth atau elevation
- Palet warna dan detail token akan didefinisikan di
docs/design-system.mdsaat modul pertama mulai dibangun, skeleton ini belum masuk ke situ - Semua keputusan visual tetap difilter lewat
ANTISLOP.mdsupaya tidak jatuh ke pola AI slop generik (gradien biru ungu template dan sejenisnya)
7. Testing dan dokumentasi #
- Unit test wajib untuk tiap service atau component, bukan opsional, pakai test harness konsisten (misal Jest untuk backend NestJS dan frontend React)
- Setiap modul punya
/testssendiri plus minimal 1 fileREADME.mdyang menjelaskan fungsi modul, cara jalanin lokal, endpoint utama, dependency ke_shared - Dokumentasi arsitektur global (ERD shared database, security policy, alur auth) ditaruh di
/docs, di update tiap ada modul baru masuk
8. Repo dan environment strategy #
| Aspek | Aturan |
|---|---|
| Environment | 3 environment: Production, Staging, Develop. Masing masing branch atau pipeline terpisah, merge terkontrol (Develop ke Staging ke Production, tidak boleh commit langsung ke Production) |
| Credential | Tidak boleh ada credential ke push. .env selalu di .gitignore, pakai .env.example sebagai template, plus secret scanning (pre commit hook atau CI check) supaya kredensial tidak lolos ke git history |
| Branch protection | Tidak ada direct push ke main atau production, wajib lewat PR plus review, hindari conflict dengan strategi branching per modul (misal feature/<modul>/<task>) |
9. Yang sengaja belum dibahas #
Dokumen skeleton jujur menyebut batasnya. Empat hal ini belum diputuskan dan tidak dibuat buat di dokumen ini.
- Daftar modul bisnis final (HR, keuangan, dan sebagainya), menunggu ditentukan
- Skema atau collection MongoDB per modul, baru didesain saat modul pertama digarap
- Dashboard dan laporan gabungan
- Detail token desain (warna, spacing scale)
10. Langkah selanjutnya #
- Setup
/Sub-program/_shareddulu: security middleware (RBAC atau SBAC, encryption, rate limit, fingerprinting) plus komponen dasar (button, input, table, modal) - Setup
/infra: docker compose untuk MongoDB plus Redis (cache) plus env template - Setup repo: branch protection, secret scanning, CI skeleton (lint plus test)
- Baru setelah fondasi ini jalan, mulai modul pertama sebagai proof of concept struktur
Dokumen sumber: PRD-ERP-Internal-Kantor-Skeleton.md versi 0.1. Wiki ini merender ulang konten tersebut menjadi format dokumentasi yang dapat dibaca di browser, dengan navigasi dan tema terang atau gelap tanpa mengubah isi PRD.