Customer Service — Scorecard Kajian

DB-12 · SV-12 — 16 tabel, cluster SAP-mirror/profile/compliance. Diagram: Helicopter View · Detail SV-12/DB-12.

Fitur: Terima mapping customer dari SAP, Get Customer Profile, Switch Profile (re-issue JWT), Compliance Doc, Get Ship To

Catatan — split dari S09/DB08 lama, D29

Sebelumnya digabung sebagai “Account & Customer Identity Service”. Sejak D29 (2026-07-20), dipecah jadi SV-09 Account dan SV-12 Customer (halaman ini) — menutup tensi T2 dengan pemetaan DDD (rekomendasi SR-04: BC-1 Customer Management dan BC-9 Identity & Access harus 2 BC terpisah). ⚠️ Pembagian tabel ini judgment call (Q18) — batasnya ternyata lebih dalam dari sekadar tabel abu-abu: ada transaksi ACID lintas domain (V12) dan fitur inti (GetBuyingProfile) yang salah taruh folder.

✅ Kandidat pertama dengan Service dan Database sama-sama berbalik ke TUNDA — beda dari kandidat lain yang cuma satu sumbu bergeser.

---

Scorecard Service (maks 16)

Kode	Kriteria	Skor	Bukti / Alasan
J1	Independent Deployability	1	GetBuyingProfile (fitur inti Cart/Simulate) ternyata ada di kode SV-12, bukan di SV-01 seperti seharusnya — deploy independen tidak semudah asumsi awal.
J2	Independent Scalability	1	Tidak ada data APM riil, pola sama semua kandidat lain.
J3	Fault Isolation (blast radius)	1	Kalau SV-12 diekstrak lalu mati, GetBuyingProfile (dipakai alur Product/Cart) ikut mati — blast radius menembus domain lain, bukan terisolasi seperti diasumsikan.
J4	Team Ownership (Conway)	1	Ditanya langsung ke user (wajib) — tidak ada testimoni tim terpisah.
J5	Technology Divergence	0	Tidak ada kebutuhan runtime/stack berbeda.
J6	Bounded Context (DDD)	1	Register/DeleteCustomer mencampur write dua domain (SV-09/SV-12) dalam satu SP. GetBuyingProfile menunjukkan batas SV-01↔SV-12 juga kabur, bukan cuma SV-09↔SV-12.
J7	Compliance / Security Isolation	2	Compliance Doc (TblM_Compliance_Doc/TblH_Compliance_Doc, dengan tabel histori/audit trail eksplisit) — data sensitif asli dengan siklus approval sendiri.
J8	Independent Lifecycle Data	2	Profil customer + compliance doc historikal beda karakter dari data transaksi Booking/Payment.
	TOTAL	9 / 16

Hard Blocker: HB1 = Tidak · HB2 = Tidak · HB3 = Tidak Keputusan: ⚠️ TUNDA (rentang 6-9) — berbalik dari placeholder 13/16 ✅ SPLIT

---

Scorecard Database (maks 14)

Kode	Kriteria	Skor	Bukti / Alasan
DB1	Independensi Transaksi	1	stp_cus_User_Register_Save/stp_cus_DeleteCustomerConfirm menulis tabel SV-12 (tblM_User_Customer, tblT_User_Compliance, tblR_User_Customer_Delete) dalam 1 unit transaksi yang sama dengan SV-09 (V12).
DB2	Independensi Foreign Key	1	FK fisik nyata tblM_User_Sales_Org (SV-12) → tblM_User (SV-09), dicek tables.sql.
DB3	Kohesi Aggregate	1	Aggregate Register/Delete tidak bisa dipisah bersih per domain — bukti sama dengan DB1.
DB4	Single Writer	1	tblM_User_Customer ditulis dari 3 titik: folder Accounts/SV-09 (Register/DeleteCustomer), FeatureAdmins/DataSP (Insert/DeleteDataSP) — multi-writer nyata, meski bukan kompetisi yang disengaja.
DB5	Master Data / Sync	1	KNA1/KNVV dipakai luas sebagai reference data (SV-01 buying profile, SV-08 Billing FK-read). Strategi replikasi sudah direncanakan tapi belum diimplementasikan penuh — masih banyak JOIN langsung.
DB6	Independensi Reporting	1	sp_Get_User_Manual_Assign (Admin FeatureAdmins/DataSP, aktif dipanggil) JOIN mentah KNA1/tblM_User_Customer untuk listing, tanpa read-model.
DB7	Stabilitas Skema (co-change)	1	0 migrasi EF Core untuk tabel SV-12 — tabel legacy pra-EF, proxy co-change tidak bisa diterapkan.
	TOTAL	7 / 14

Hard Blocker: DHB1 = Tidak · DHB2 = Tidak — semua skor rendah tapi tidak ada yang menyentuh 0. Keputusan: ⚠️ TUNDA (rentang 5-8) — berbalik dari placeholder 13/14 ✅ PISAH DATA

---

Temuan tambahan (sesi validasi 2026-07-28)

• 🔴 GetBuyingProfileQueryHandler melanggar D4 — satu-satunya implementasi ada di folder Customer (SV-12), bukan Products (SV-01) seperti diputuskan. Dicatat sebagai backlog pemindahan kode prioritas (D4 tetap arah target).
• 🔴 Write lintas domain dua arah: SV-09→SV-12 (Register/DeleteCustomer, V12) dan SV-12→SV-09 (UpdateOtpProviderCommandHandler menulis tblM_User.OtpProviderId).
• 🟢 Gap DDD G1 (Ship-To management) ditutup — GetCustomerShipToQueryHandler sudah ada, cuma belum pernah tercatat.
• Semua dicatat sebagai perluasan V12 di backlog pelanggaran lintas-service.

---

Rekomendasi Akhir

Rapikan jadi modul internal dulu — BELUM layak dipisah sebagai unit kode/deploy sendiri. Beda dari SV-09 (yang masih boleh “pisah kode dulu, data shared”), SV-12 gagal di kedua sumbu sekaligus. Prioritas sebelum dipertimbangkan ulang: (a) pindahkan GetBuyingProfile ke SV-01 sesuai D4, (b) desain saga/kompensasi untuk Register & DeleteCustomer, (c) perbaiki UpdateOtpProvider (pindah kolom OtpProviderId ke kepemilikan SV-12 atau panggil API SV-09), (d) konsolidasikan 3 titik tulis tblM_User_Customer jadi satu jalur resmi.