Account Service — Scorecard Kajian

DB-09 · SV-09 — 10 tabel, cluster identitas/login. Diagram: Helicopter View · Detail SV-09/DB-09.

Fitur: Register, Login Customer (CIAM), Idaman, Forgot Password, OTP, Logout, Single Session (warisan), Refresh Token (warisan)

Catatan — split dari S09/DB08 lama, D29

Sebelumnya digabung sebagai “Account & Customer Identity Service”. Sejak D29 (2026-07-20), dipecah jadi SV-09 Account (halaman ini) dan SV-12 Customer — menutup tensi T2 dengan pemetaan DDD (rekomendasi SR-04: BC-1 Customer Management dan BC-9 Identity & Access harus 2 BC terpisah). ⚠️ Pembagian tabel judgment call (Q18) — pemisahan ini ternyata lebih dalam masalahnya dari sekadar tabel abu-abu (lihat scorecard Database di bawah).

Skor Database berbalik dari placeholder 14/14 (✅ PISAH DATA) menjadi 7/14 (⚠️ TUNDA) — beda dari pola SV-03/SV-05/SV-07, di sini Database yang berubah kelas, bukan Service.

---

Scorecard Service (maks 16)

Kode	Kriteria	Skor	Bukti / Alasan
J1	Independent Deployability	1	Folder kode FeatureCustomers/Accounts mencampur handler SV-09 (login/OTP/register) dengan fitur SV-12 (DeleteCustomer/GetCustomerDetail/GetSwitchProfiles) — Register/DeleteCustomer menulis tabel kedua domain sekaligus, 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)	2	Desain JWT-claims: begitu token terbit, domain lain tidak panggil balik ke Identity per-request. Kalau SV-09 mati, sesi dengan JWT valid tetap bisa transaksi di domain lain — cuma login baru/refresh yang kena.
J4	Team Ownership (Conway)	1	Ditanya langsung ke user — tidak ada testimoni tim terpisah yang menangani domain ini secara khusus.
J5	Technology Divergence	0	Tidak ada kebutuhan runtime/stack berbeda.
J6	Bounded Context (DDD)	1	SP Register/DeleteCustomer mencampur write kedua domain dalam 1 SP, bukan cuma berbagi junction table seperti dikira sebelumnya. Bounded context SV-09 vs SV-12 jauh lebih kabur dari yang tercatat di D29.
J7	Compliance / Security Isolation	2	Password hash+salt (Password/Password_Key), OTP, refresh token, recaptcha — pola credential/PII yang jelas beda karakter dari domain lain.
J8	Independent Lifecycle Data	2	OTP/verify-code/refresh-token semua punya expiry/lifecycle sendiri (ExpiredDate, IsRevoked), independen dari data permanen (Booking dst).
	TOTAL	10 / 16

Hard Blocker: HB1 = Tidak · HB2 = Tidak · HB3 = Tidak Keputusan: ✅ SPLIT (persis di ambang bawah)

---

Scorecard Database (maks 14)

Kode	Kriteria	Skor	Bukti / Alasan
DB1	Independensi Transaksi	1	stp_cus_User_Register_Save (Registrasi, BEGIN TRANSACTION eksplisit) menulis tblM_User+tblT_User_Register_VerifyCode (SV-09) dan tblT_User_Compliance+tblM_User_Customer (SV-12) dalam 1 unit atomik. stp_cus_DeleteCustomerConfirm menulis tblM_User+tblT_UserRefreshToken (SV-09) dan tblM_User_Customer+tblR_User_Customer_Delete (SV-12) dalam 1 pemanggilan SP. Toleran eventual consistency (bukan 0) — bisa didesain ulang jadi 2 langkah + kompensasi.
DB2	Independensi Foreign Key	1	FK fisik nyata di tables.sql: tblM_User_Sales_Org (SV-12) → tblM_User.Email (SV-09) — bukan sekadar FK-read app-level.
DB3	Kohesi Aggregate	1	Aggregate Register/Delete tidak bisa dipisah bersih per domain, bukti sama seperti DB1.
DB4	Single Writer	1	tblH_User_Login (milik SV-09) ditulis dari 4 titik luar domain (SV-01/SV-07×2/SV-04) lewat SP “Get” yang disalahgunakan (V6). Bukan kompetisi tulis yang disengaja, tapi tetap multi-writer nyata.
DB5	Master Data / Sync	1	tblM_User dibaca sebagai referensi oleh 4 domain luar (V6) tanpa strategi sync resmi — masih direct-SQL, bukan API/replikasi yang didesain.
DB6	Independensi Reporting	1	sp_Get_User_Manual_Assign (Admin FeatureAdmins/DataSP, aktif dipanggil) JOIN mentah tblM_User+KNA1+tblM_User_Customer untuk listing, tanpa read-model.
DB7	Stabilitas Skema (co-change)	1	0 migrasi EF Core untuk tabel SV-09 — tabel legacy pra-EF, jadi pola co-change lewat migrasi tidak bisa dicek.
	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 14/14 ✅ PISAH DATA

---

Temuan tambahan (sesi validasi 2026-07-28)

• Folder FeatureCustomers/Accounts mencampur domain SV-09 dan SV-12 dalam handler & SP yang sama — scan 26 SP yang dipanggil dari folder ini menunjukkan mayoritas menyentuh tabel kedua domain sekaligus.
• FK fisik nyata tblM_User_Sales_Org (SV-12) → tblM_User (SV-09).
• Fitur admin baru, belum pernah tercatat: FeatureAdmins/DataSP (InsertDataSP/DeleteDataSP/GetDataSP) — “Manual Assign” nomor customer ke user, baca-tulis tblM_User_Customer + baca tblM_User/KNA1 untuk validasi.
• Semua dicatat sebagai V12 baru di backlog pelanggaran lintas-service.

---

Rekomendasi Akhir

Pisah KODE dulu, data tetap shared/transisi — Service layak dipisah (10/16, mepet) TAPI Database belum layak (7/14, TUNDA). SV-09 boleh mulai dipisah sebagai unit kode/deploy, tapi DB-09/DB-12 belum boleh dipisah fisik sampai: (a) saga/kompensasi untuk Register & DeleteCustomer dirancang, (b) FK tblM_User_Sales_Org→tblM_User diganti API/replikasi, (c) V6 diperbaiki (fix murah, solusi sudah diketahui sejak validasi SV-01), (d) sp_Get_User_Manual_Assign dipindah ke read-model/API.