# Roadmap Migrasi ERP Enterprise: Dari CodeIgniter 3 ke Domain-Driven Design (DDD)

Dokumen ini berisi peta jalan (roadmap) strategis dan teknis untuk melakukan migrasi aplikasi ERP Monolith (CodeIgniter 3) dengan *Fat Controller* (40.000+ LOC) menuju arsitektur modern berstandar *Enterprise Grade* (Next.js + Core Domain Engine).

## 📊 Ringkasan Target & Batasan Sistem
*   **Kondisi Saat Ini:** CodeIgniter 3, Gaya Prosedural/Active Record, *Fat Controller* Penjualan (40k+ LOC), Tanpa *Unit Testing*.
*   **Infrastruktur:** *Multi-Database* (1 *Dedicated Database* per Klien).
*   **Skala Bisnis:** 10 Klien Aktif (Rata-rata 1.000 karyawan per klien) $\rightarrow$ Target Skalabilitas: **100+ Klien (100.000+ User Aktif)**.
*   **Strategi Migrasi:** *Strangler Fig Pattern* (Migrasi Bertahap) & *Pragmatic DDD*.

---

## 🟢 FASE 1: Isolasi & Pembersihan Domain (Di Dalam CI3 Lama)
**Target Horizon:** Bulan 1 – Bulan 3  
**Fokus Utama:** Menjinakkan "Monster" 40.000 Baris tanpa Mengubah Framework (Meminimalkan Risiko Regresi).

Sebelum melompat ke bahasa atau framework baru, tim harus merapikan logika bisnis di dalam sistem lama agar tidak memindahkan "sampah arsitektur" ke sistem baru.

### 📌 Langkah Eksekusi Teknis:
1.  **Ekstraksi Logika Bisnis (*Fat Controller Dissecting*):**
    *   Bongkar fungsi transaksional padat seperti `create_so()` atau `scan_serial()`.
    *   Pindahkan semua logika validasi, hitungan diskon bertingkat, PPN, dan aturan otorisasi keluar dari controller.
    *   Masukkan ke dalam *Plain Old PHP Class* (Kelas PHP murni bebas dari *inherit* kelas CI3) di folder baru: `application/domains/sales/`.
2.  **Abstraksi Akses Database (*Repository Pattern Isolation*):**
    *   Hilangkan perintah Active Record langsung seperti `$this->db->insert()` atau `$this->db->get()` dari dalam logika bisnis.
    *   Ganti dengan memanggil sebuah *Interface Repository*. Logika bisnis hanya tahu cara meminta data, bukan cara query data.
3.  **Implementasi *Unit Testing* Pertama:**
    *   Karena logika bisnis sudah menjadi kelas PHP murni yang terisolasi, tim kini bisa memasang **PHPUnit**.
    *   Buat *test case* ketat khusus untuk mengunci kebenaran kalkulasi finansial (nilai SO/Invoicing) dan validasi stok.

---

## 🟡 FASE 2: Jembatan Transisi & Modernisasi Stack (Laravel + Next.js)
**Target Horizon:** Bulan 4 – Bulan 9  
**Fokus Utama:** Modernisasi UI/UX, Penerapan *Dynamic Multi-Tenancy*, dan Naik Kelas ke PHP OOP Modern.

Fase ini memindahkan modul yang sudah rapi ke sistem baru. Laravel dipilih sebagai backend jembatan agar tim tidak mengalami *culture shock* bahasa baru (tetap menggunakan PHP 8+), sementara Next.js digunakan untuk menangani performa frontend (seperti *Scanner Serial*).

### 📌 Langkah Eksekusi Teknis:
1.  **Arsitektur *Dynamic Multi-Database Routing*:**
    *   Gunakan *library* matang seperti `stancl/tenancy` di Laravel.
    *   Sistem harus bisa mendeteksi asal klien secara dinamis berdasarkan subdomain atau *Custom HTTP Header* dari Next.js, lalu mengarahkan koneksi ke database klien yang tepat saat *runtime*.
2.  **Porting ke Struktur Folder Berbasis Domain:**
    *   Pindahkan kelas domain dari Fase 1 ke Laravel. Jangan gunakan struktur folder MVC bawaan Laravel.
    *   Buat struktur folder berbasis komponen domain bisnis, contohnya: `app/Domains/Sales/` dan `app/Domains/Logistics/`.
3.  **Strategi *Dual Write / Shadow Testing* (Penyelamat Tanpa Downtime):**
    *   Saat frontend Next.js mengirim data (misal pembuatan SO), arahkan *request* ke Laravel baru.
    *   Laravel memproses data, namun sebelum melakukan *commit* ke database, Laravel secara diam-diam menembak API rahasia ke CI3 lama untuk mencocokkan hasil kalkulasi internalnya.
    *   Jika hasil kalkulasi Laravel dan CI3 sinkron 100% selama 2-4 minggu, matikan jalur CI3 lama untuk sub-modul tersebut.

---

## 🔵 FASE 3: True Enterprise Platform (Go / .NET Core Core Engine)
**Target Horizon:** Jangka J Panjang (Saat Klien Menuju 30 – 100+)  
**Fokus Utama:** Performa Konkurensi Ekstrem, Keamanan Jangka Panjang, dan *Framework Independence*.

Ketika jumlah klien mendekati angka 100 dengan total 100.000+ karyawan aktif, fitur transaksional intensif (seperti data masuk dari ribuan *Scanner Serial* secara bersamaan) akan mulai membebani batas maksimal konkurensi PHP (Laravel).

### 📌 Langkah Eksekusi Teknis:
1.  **Identifikasi *Bottleneck* Modul Bisnis:**
    *   Pisahkan modul yang bersifat *CRUD biasa* (seperti Manajemen User, Master Data, Invoicing) dengan modul yang bersifat *High-Throughput/Beban Tinggi* (seperti *Scanner Serial* & *Logistics*).
2.  **Ekstraksi Modul Menjadi *Microservice* Sejati:**
    *   Cabut folder Domain *Logistics* dari Laravel. Karena kodenya sudah terisolasi dengan prinsip DDD sejak Fase 2, pencabutan ini tidak akan merusak modul lainnya.
    *   Tulis ulang modul *Logistics* tersebut menggunakan **Go (Golang)** atau **.NET Core (C#)** untuk mendapatkan fitur *multi-threading* murni dan *connection pooling* tingkat tinggi langsung di level memori untuk ratusan database.
3.  **Integrasi via *API Gateway*:**
    *   Frontend Next.js tidak perlu tahu perubahan di sisi backend. Next.js tetap menembak satu titik URL yang sama.
    *   *API Gateway* (seperti Kong atau Envoy) yang akan bertugas mengarahkan lalu lintas data: urusan Sales/Invoicing dikirim ke Laravel, sedangkan urusan Scanner/Logistik dikirim ke Core Engine berbasis Go/.NET.

---

## 💡 Mengapa Strategi Ini Paling Bijaksana?
1.  **Mitigasi Risiko Kegagalan Bisnis (Zero Downtime):** Migrasi dilakukan secara dicicil per sub-modul menggunakan metode *Strangler Fig* dan dilindungi oleh *Shadow Testing*. Operasional 10 perusahaan klien Anda dijamin aman dari *bug* fatal.
2.  **Menjaga Psikologis & Kapasitas Tim:** Developer Anda naik kelas secara bertahap tanpa dipaksa menelan terlalu banyak hal baru sekaligus. Beban belajar dibagi rata: (Fase 1: Belajar OOP/Testing) $\rightarrow$ (Fase 2: Belajar Arsitektur Modular/API) $\rightarrow$ (Fase 3: Belajar Bahasa Baru Performa Tinggi).
3.  **Bebas dari Kekangan Framework (*Future-Proof*):** ERP Anda tidak lagi bergantung pada siklus hidup sebuah framework umum. Anda sedang membangun aset teknologi berupa *Core Enterprise Platform Engine* milik perusahaan Anda sendiri yang siap bertahan hingga 20 tahun ke depan.