EVoucher Service — Scorecard Kajian

DB-04 · SV-04 — 9 tabel (tblT_EVoucher*, tblM_EVoucher*). Diagram: Helicopter View · Detail SV-04/DB-04.

Fitur: F01 Simulate, F02 Create Booking, F03 Get Token LinkAja, F04 Cancel Transaction EVoucher

📁 Folder kode: F03 (GetTokenLinkAjaCommandHandler)/F04 (CancelTransEvoucherCommandHandler) + 1 query ada di FeatureCustomers/Evoucher sendiri. F01/F02 TIDAK ada di situ — tertanam langsung di PaymentCommandHandler.cs (SV-02), lihat catatan di bawah.

Scorecard divalidasi penuh 2026-07-28 — D53–D54

Skor Service turun dari 14 ke 11/16 (tetap ✅ SPLIT, ≥10). Skor Database turun dari 14 ke 13/14 (tetap ✅ PISAH DATA). Alur transaksi utama eVoucher (F01 Simulate, F02 Create Booking) ternyata tertanam di kode SV-02 (PaymentCommandHandler.cs), bukan di folder SV-04 sendiri — J1 turun karena ini. User secara eksplisit mengusulkan pemisahan penuh F01/F02 keluar dari kode Payment sebagai prioritas tinggi (lihat Rekomendasi Akhir). Detail penuh: 02-decisions.md D54.

---

Scorecard Service (maks 16)

Kode	Kriteria	Skor	Bukti / Alasan
J1	Independent Deployability	1 ⚠️	F01 (Simulate)/F02 (Create Booking) tertanam di PaymentCommandHandler.cs (SV-02, baris 301-302 & 695-704), memanggil stp_cus_Evoucher_Save langsung — bukan di folder Evoucher sendiri yang cuma berisi F03/F04. Alur transaksi utama eVoucher tidak bisa di-deploy terpisah dari SV-02 saat ini. Data DB-04 sudah independen, tapi itu independensi data, bukan kode/deploy. User mengusulkan pemisahan penuh F01/F02 sebagai prioritas (lihat Rekomendasi Akhir).
J2	Independent Scalability	1	Tidak ada data APM. Folder Evoucher sendiri sangat tipis (3 handler) — tidak ada bukti profil beban yang berbeda.
J3	Fault Isolation (blast radius)	2	F01 cuma snapshot DB-01, F02 langsung Approved tanpa hop, F03/F04 hop terbatas (LinkAja + 1 pelanggaran V6). Kegagalan LinkAja tidak merembet ke Booking non-eVoucher.
J4	Team Ownership (Conway)	2	User memberi testimoni eksplisit: tim dev eVoucher berbeda dari tim booking non-eVoucher. Skor 2 karena ini bukan asumsi struktural, tapi pernyataan langsung dari user soal pemisahan tim yang sudah ada.
J5	Technology Divergence	0	Tidak ada kebutuhan stack berbeda.
J6	Bounded Context (DDD)	2	Bukti admin CRUD nyata (Contract Management, Corporate Gift) menunjukkan domain yang jelas. DDD (10-ddd-mapping.md) juga memetakan BC-10 eVoucher sebagai tercover penuh.
J7	Compliance / Security Isolation	1	Ditemukan EvoucherService.Encrypt() — email & nama customer dienkripsi sebelum dikirim ke LinkAja (GetToken(), F03). Sinyal nyata tapi cakupan sempit (1 dari 4 fitur), sama kelas dengan FileEncryptionHelper SV-02.
J8	Independent Lifecycle Data	2	Siklus approval eVoucher beda total dari Booking biasa — langsung Approved tanpa Debit/Credit Note (06-payment-methods.md).
	TOTAL	11 / 16	Tetap ✅ SPLIT (≥10), turun dari skor awal 14/16.

Hard Blocker: HB1 = Tidak · HB2 = Tidak · HB3 = Tidak Keputusan: ✅ SPLIT — dengan syarat prioritas: selesaikan dulu pemisahan kode F01/F02 dari SV-02 (lihat Rekomendasi Akhir).

---

Scorecard Database (maks 14)

Kode	Kriteria	Skor	Bukti / Alasan
DB1	Independensi Transaksi	2	Pola snapshot, tidak butuh transaksi ACID bersama Booking. Tidak ditemukan jalur RetryCreateSODO/OrderHistory (Admin) yang menyentuh domain eVoucher — beda dari SV-02/SV-03.
DB2	Independensi Foreign Key	2	FK-referensi read-only snapshot ke DB-01 saja, dibaca sekali saat Simulate.
DB3	Kohesi Aggregate	2	9 tabel DB-04 kohesif sebagai satu domain eVoucher.
DB4	Single Writer	2	SP kembar sp_EVoucher_* vs stp_cus_Evoucher_* ditemukan, tapi semuanya dipanggil dari EvoucherService.cs (infrastructure layer, dipakai fitur customer SV-04 sendiri via IEvoucherService) — bukan folder Admin terpisah, cuma konvensi penamaan SP yang tidak konsisten. V6 kejadian ke-4 (GetTokenLinkAjaCommandHandler menulis tblH_User_Login milik SV-09) tetap pelanggaran outbound, tapi tidak memengaruhi DB4 SV-04 sendiri.
DB5	Master Data / Sync	1	tblT_EVoucher* di-query langsung (raw SP, tanpa API/event) oleh GetBookingDetailEvoucherQueryHandler (SV-02) dan GetTransactionEvoucherDetailQueryHandler (SV-03). Skor 1, bukan 0 seperti SV-03 — cuma 2 query detail-view read-only, bukan dependensi operasional inti berulang.
DB6	Independensi Reporting	2	Tidak ada JOIN olap/reporting Admin Dashboard yang menyentuh tabel eVoucher.
DB7	Stabilitas Skema (co-change)	2	Tidak ada migrasi EF individual yang menyentuh tabel eVoucher sejak baseline.
	TOTAL	13 / 14	Tetap ✅ PISAH DATA, turun 1 poin dari skor awal (DB5).

Hard Blocker: DHB1 = Tidak · DHB2 = Tidak Keputusan: ✅ PISAH DATA

---

Rekomendasi Akhir

FULL MICROSERVICE (DB sendiri) — SPLIT (service) + PISAH DATA (database) — tapi dengan syarat prioritas tinggi berbeda dari kandidat lain.

Syarat sebelum eksekusi (urutan prioritas):

1. 🔴 Pisahkan F01 (Simulate)/F02 (Create Booking) dari PaymentCommandHandler.cs jadi handler SV-04 sendiri (memanggil SV-01 untuk snapshot produk, pola sama service lain) — diminta eksplisit oleh user sebagai prioritas tinggi. Beda dari SV-02/SV-03 yang mekanismenya masih “belum diputuskan” — di sini arahnya sudah jelas, tinggal implementasi.
2. Desain strategi sync untuk DB5 (SV-02/SV-03 konsumsi tblT_EVoucher* langsung) — API/event, bukan raw SP query.
3. Tutup V6 kejadian ke-4 (GetTokenLinkAjaCommandHandler menulis tblH_User_Login) — sesuai arah D31 (ganti ke SP baca-saja milik SV-09).
4. Kalau data APM/traffic riil berhasil didapat, cek ulang J2.