Simulate, Payment Service (Transaction) — Scorecard Kajian

DB-02 · SV-02 — 11 tabel dimiliki (tblT_Simulate_*, tblT_FD_No, tblT_Pending_Debet, tblT_Saldo, tblM_Customer_Saldo, tblM_Bank_Opr_Time, tblM_CustomerAutoFin, tblM_CustomerDistFin). Diagram: Helicopter View · Detail SV-02/DB-02.

Kode fitur Fxx di bawah mengacu ke peta fitur SV-02 (F01 Simulate Price … F15 Buy Now — lihat Detail SV-02.

---

Scorecard Service (maks 16)

Kode	Kriteria	Skor	Bukti / Alasan
J1	Independent Deployability	2	SP milik Payment (55) sama sekali terpisah dari SP Products/Cart (36+17). Booking Order direncanakan ditulis oleh SV-03, dipanggil lewat gRPC/event — bukan SQL langsung dari SV-02.
J2	Independent Scalability	⚠️ 1	Tidak ada data APM/traffic riil. Rasio handler Query:Command 31:7 (82% baca), tanpa caching sama sekali. Beban Payment bersifat I/O-bound — blocking call ke SAP/Bank/AutoFinance/DistFinance/OTC — beda jenis dari Product Catalog yang murni DB-read lokal.
J3	Fault Isolation (blast radius)	2	7 dependensi eksternal terpetakan (SAP, OTC, Bank, AutoFinance/DistFinance, Blob, SV-05, SV-03) — kegagalan di satu integrasi (mis. AF/DF) tidak merembet ke metode bayar lain.
J4	Team Ownership (Conway)	⚠️ 1	Belum ada tim khusus yang menangani seluruh fitur Payment terpisah dari domain lain. Tapi boundary domain SV-02 sudah jelas (lihat J6), sehingga ownership dan deployment mandiri tetap memungkinkan tanpa melibatkan tim lain yang tidak berkepentingan.
J5	Technology Divergence	0	Tidak ada kebutuhan stack berbeda.
J6	Bounded Context (DDD)	2	Payment tetap modul internal yang terpisah dari Booking Order karena siklus tulisnya beda. DDD memetakan Payment dan Booking/SO sebagai satu bounded context (BC-5), beda dari pembagian SV-02/SV-03 di sini — tapi keputusan pemisahan ini tetap dipertahankan.
J7	Compliance / Security Isolation	1	Ditemukan enkripsi file PO sebelum disimpan ke Blob (UploadPOCommandHandler, F06 ZOR) — tapi cakupannya sempit, cuma 1 dari ~15 fitur Payment. Tidak ada data kartu/rekening mentah yang lewat sistem ini langsung — semua dikirim ke Bank/AutoFinance/DistFinance lewat WSDL/REST eksternal.
J8	Independent Lifecycle Data	1	Setelah Booking Order pindah ke DB-03, sisa tabel DB-02 lebih homogen (Simulate + Saldo). Tapi tblM_Customer_Saldo masih ada di sini, dan siklus hidupnya tidak murni milik satu transaksi Booking — tabel ini ditulis dari dua jalur berbeda, bukan cuma dari Payment.
	TOTAL	10 / 16

Hard Blocker: HB1 = Tidak · HB2 = Tidak · HB3 = Tidak (dicek migrasi EF — DB-02 tidak pernah co-change dengan domain lain) Keputusan: ✅ SPLIT — mepet, sama pola seperti SV-01.

---

Scorecard Database (maks 14)

Kode	Kriteria	Skor	Bukti / Alasan
DB1	Independensi Transaksi	1 ⚠️	Alur normal Create Booking tidak butuh transaksi lintas database — SV-02 kirim payload, SV-03 commit sendiri. Tapi jalur admin RetryCreateSODO menjalankan satu transaksi yang menulis baik Saldo (DB-02) maupun Booking/SO (DB-03) sekaligus, tanpa rollback/kompensasi. Status pemakaian jalur ini di produksi masih perlu dicek ke tim (Q20).
DB2	Independensi Foreign Key	2	FK-referensi (KNA1, KNVV, tblM_Bank*, tblM_Payment_Method*, dst) seluruhnya bersifat read-only snapshot, bukan live FK constraint, tidak ada FK inti yang putus.
DB3	Kohesi Aggregate	2	11 tabel (Simulate_Group/Item, FD_No, Pending_Debet, Saldo*, Bank_Opr_Time, CustomerAutoFin/DistFin) kohesif sebagai satu domain simulasi harga & escrow/limit pembayaran, tanpa tercampur data Booking permanen.
DB4	Single Writer	1 ⚠️	tblM_Customer_Saldo/tblT_Saldo ditulis dari dua jalur: Payment (stp_cus_Update_Saldo_Customer) dan SP kembar identik sp_Update_Saldo_Customer yang dipanggil dari Admin RetryCreateSODO/OrderHistory (retry SO/DO, approval order), tanpa guard idempotency. Berbeda dari jalur IsTopup (V5) yang sudah terbukti tidak dipakai lagi, status jalur admin ini masih perlu dicek ke tim.
DB5	Master Data / Sync	2	Tidak ditemukan domain lain yang memakai tabel DB-02 sebagai data referensi. Bukan shared data, tidak butuh strategi sync.
DB6	Independensi Reporting	2	SP olap Admin Dashboard (sumber JOIN MARA di SV-01) tidak menyentuh tabel DB-02. stp_cus_dashboard_myTransaction (SV-11) juga query ke DB-03, bukan DB-02. Bersih.
DB7	Stabilitas Skema (co-change)	2	Migrasi EF individual tidak ada yang menyentuh tabel DB-02 sejak awal — lebih bersih dari SV-01 yang masih punya 3 migrasi domain-pure.
	TOTAL	12 / 14

Hard Blocker: DHB1 = Tidak, tapi perlu verifikasi (temuan RetryCreateSODO lintas DB-02/DB-03) · DHB2 = Tidak, tapi perlu verifikasi (lihat DB4) Keputusan: ✅ PISAH DATA — turun dari DB1 dan DB4, tapi margin masih nyaman di atas ambang (≥9). Klarifikasi DB4 wajib sebelum eksekusi nyata.

---

Rekomendasi Akhir

FULL MICROSERVICE (DB sendiri) — SPLIT (service, mepet di ambang) + PISAH DATA (database, margin nyaman).

Syarat sebelum eksekusi:

1. 🔴 Klarifikasi status bisnis SP sp_Update_Saldo_Customer (Admin RetryCreateSODO/OrderHistory) — apakah masih rutin dipakai, dan apakah ada risiko double-deduction saldo kalau dijalankan setelah Payment normal sukses. Ini menentukan apakah DB4 harus turun ke 0 (hard blocker) atau memang aman seperti jalur IsTopup (V5) yang sudah terbukti dead.
2. Tutup V7 — akses langsung DB Aviasi (tblM_MappingIATASH, jalur IntoPlane di F09) harus jadi API call, bukan query lintas-database langsung.
3. Selesaikan arah kepemilikan V5 (tblM_Customer_Saldo, jalur IsTopup Payment) — arah sudah disepakati (deprekasi jalur saldo internal), tinggal eksekusi & verifikasi tim sebelum dihapus/dipindah.
4. Desain mekanisme SV-02→SV-03 (gRPC vs event-driven) untuk Create Booking — keputusan arsitektur yang masih terbuka, termasuk strategi idempotency (bagaimana kalau SV-02 kirim payload tapi SV-03 gagal commit, atau sebaliknya).
5. Perbaiki F1 (error SendInvoice AF/DF yang ditelan diam-diam) sebelum melepas jalur AF/DF ke luar monolith — perilaku ini akan makin berisiko begitu jadi network call antar service.
6. Kalau data APM/traffic riil berhasil didapat, cek ulang J2 dulu (sama seperti SV-01) — TOTAL Service persis di ambang bawah, turun 1 poin saja bisa berbalik ke ⚠️ TUNDA.