# Rencana Migrasi Arsitektur: Monolithic ke Modular Monolith

Rencana ini menjabarkan strategi bertahap untuk memigrasikan database *holding* (`san_30mar`) yang memiliki arsitektur Monolithic (tabel tunggal `transaksi_data_registry` dengan `longblob`) menjadi arsitektur Modular Monolith seperti anak perusahaannya (`san_tsa_28agu` dengan awalan tabel per modul).

Mengingat ERP ini memiliki 50+ modul dengan lalu lintas data yang sangat padat, pendekatan "Big Bang" (mengubah semuanya dalam satu malam) sangat tidak disarankan karena risiko kegagalan sistem 100%. Kita akan menggunakan pendekatan **Strangler Fig Pattern** (Migrasi Bertahap per Modul).

## User Review Required

> [!CAUTION]
> **Risiko Operasional & Estimasi Waktu:**
> Proyek migrasi ini diproyeksikan memakan waktu **6 hingga 12 bulan**. Proses ini tidak hanya melibatkan perubahan database, tetapi juga mewajibkan *programmer* untuk merombak logika kode (*source code* PHP CodeIgniter) di seluruh 50+ modul agar menyesuaikan dengan struktur tabel yang baru. 
> 
> **Mohon konfirmasi:** Apakah saat ini perusahaan memiliki kapasitas *developer* dan toleransi waktu yang cukup untuk menjalankan proyek jangka panjang ini? Jika prioritas utamanya hanyalah membebaskan *storage* dalam waktu dekat (1-2 bulan), metode **Database Cut-Off (Tutup Buku)** seperti yang tertulis di catatan diskusi tetap menjadi solusi paling direkomendasikan.

## Open Questions

> [!WARNING]
> 1. **Daftar Modul Prioritas:** Dari 50+ modul, modul manakah yang ukuran datanya paling besar atau paling sering diakses? (Misal: Pembelian, Penjualan, Gudang). Kita harus memulai migrasi dari modul dengan risiko terendah atau modul dengan beban terberat terlebih dahulu (tergantung strategi manajemen risiko).
> 2. **Kesiapan CodeIgniter:** Apakah ERP ini menggunakan sistem *Object-Relational Mapping (ORM)* atau Active Record standar bawaan CodeIgniter? Memiliki ORM akan mempermudah *mapping* ke struktur tabel baru.

---

## Proposed Changes (Fase Migrasi Bertahap)

Kita tidak akan merobohkan rumah lama secara langsung, melainkan memindahkannya kamar demi kamar. Berikut adalah fase perencanaannya:

### Fase 1: Persiapan & Standarisasi (Bulan 1)
- **Mapping Struktur Data:** Melakukan *mapping* struktur JSON/`longblob` yang ada di tabel `san_30mar.transaksi_data_registry` untuk diterjemahkan ke dalam 11 kolom fisik (kolom relasional) yang sesuai dengan struktur `san_tsa_28agu`.
- **Pembuatan Class Adapter:** Membuat jembatan (Adapter) di kode PHP agar sistem lama masih bisa membaca dari tabel baru jika diperlukan.

### Fase 2: Implementasi Per Modul - Contoh: Modul Pembelian (Bulan 2)
Kita ambil Modul Pembelian sebagai *pilot project*.

#### [NEW] Database Schema 
Pembuatan tabel khusus pembelian di database `san_30mar`:
- Pembuatan tabel `pembelian_transaksi_data_registry` (struktur 11 kolom tanpa `longblob` berlebih).
- Pembuatan relasi dan *Index* untuk optimasi *query*.

#### [MODIFY] Kode PHP Modul Pembelian (CodeIgniter)
- Mengubah *Controller* dan *Model* pada modul Pembelian untuk membaca dan menulis data (Insert/Update/Select) secara eksklusif ke tabel `pembelian_transaksi_data_registry`, bukan lagi ke tabel global.

### Fase 3: Dual-Write & Data Backfill (Bulan 2-3)
- **Dual-Write (Opsional jika tanpa downtime):** Saat modul Pembelian versi baru di-*deploy*, aplikasi akan menulis transaksi baru ke tabel `pembelian_*` DAN (sementara) ke tabel global lama agar modul lain yang belum dimigrasi (seperti Akuntansi) tidak pecah.
- **Backfill:** Membuat *script* migrasi (Cron Job) di *background* untuk membaca jutaan data histori `longblob` pembelian di tabel lama, mengekstrak nilainya, lalu menyimpannya ke dalam 11 kolom rapi di tabel `pembelian_*`.

### Fase 4: Cut-Over & Pembersihan Modul Pembelian
- Setelah semua data historis tersalin dan tervalidasi 100% akurat.
- Koneksi modul Pembelian ke tabel global lama diputus total (*Hard Cut-Over*).
- Menghapus data *blob* pembelian yang ada di tabel global untuk membebaskan ruang penyimpanan (*Storage Recovery*).

### Fase 5: Iterasi (Bulan 4-12)
- Mengulangi **Fase 2 hingga Fase 4** untuk Modul Penjualan, HRD, Gudang, Produksi, dan sisa 45+ modul lainnya satu per satu hingga tabel raksasa `transaksi_data_registry` sepenuhnya kosong dan bisa dihapus permanen.

---

## Verification Plan

Untuk memastikan migrasi arsitektur ini tidak merusak data bisnis (*zero data loss*):

### Automated & Data Tests
- **Data Integrity Checker:** Membuat *script* Python atau PHP yang membandingkan total Rupiah atau jumlah kuantitas (*Checksum*) antara data yang ada di `longblob` lama dengan data yang sudah dipindahkan ke 11 kolom baru (`pembelian_*`). Kedua nilai harus *balance* 100%.

### Manual Verification
- Melakukan *Dry Run* (simulasi) di *server staging* bersama dengan perwakilan setiap divisi. Perwakilan (misal: Kepala Pembelian) harus memverifikasi bahwa semua histori transaksinya muncul dengan benar menggunakan skema yang baru sebelum kode naik ke *Production*.