Booking Order Service (History) — Scorecard Kajian

DB-03 · SV-03 — 14 tabel (tblT_Booking_*, tblT_Sales_Order*, tblT_PO, tblH_Booking_Order_Status_History, +1 scheduler). Diagram: Helicopter View · Detail SV-03/DB-03.

Fitur: F01 Booking History, F02 Booking Check Status/Resend AF-DF, F03 Proof of Order, F04 Booking Order Rating, F05 Auto-Cancel + Email Reminder, F06 Terima Create Booking dari SV-02 (baru, D28), F07 Retry Create SO/DO Manual (FeatureAdmins/RetryCreateSODO, baru ditemukan D49), F08 Approval/Adjustment Order Detail (FeatureAdmins/History/OrderHistory, baru ditemukan D49)

📁 Folder kode aktual: FeatureCustomers/TransactionHistory (F01-F04) + FeatureCustomers/Payment/Scheduler (F05) — bukan folder bernama “Booking”/“History” seperti dugaan draf lama.

Catatan

DB-03 baru hasil pemisahan DB-02 (D28, 2026-07-17) — sebelumnya SV-03 berbagi DB-02 dengan SV-02. Sekarang SV-03 jadi penulis utama Booking/Sales/PO, bukan cuma pembaca histori. Arsitektur target (SV-02 kirim payload via gRPC/event) belum diimplementasi di kode — saat ini stp_cus_Booking_Order_Save masih menulis langsung dari alur Payment/SV-02.

Scorecard divalidasi penuh 2026-07-28 — D49–D50 — keputusan BERBALIK ke TUNDA

Skor Service turun dari 10 ke 8/16 — turun dari ambang ✅ SPLIT ke rentang ⚠️ TUNDA (6-9). Skor Database turun dari 13 ke 10/14 setelah dua koreksi: DB5 turun 1→0 karena SV-11 Dashboard sangat bergantung ke data histori transaksi ini, dan DB6 naik 1→2 karena JOIN yang ditemukan ternyata ada di skrip populate/ETL read-model, bukan di jalur serving. Tetap ✅ PISAH DATA dengan margin wajar, tapi DB5=0 tetap jadi sinyal warning.

Kepemilikan tabel tetap seperti sebelumnya (D28, tidak dibongkar) — yang berubah cuma rekomendasi scorecard: sebagai service independen, SV-03 belum layak dipisah jaringan sekarang, disarankan jadi modul internal dulu (kemungkinan menempel SV-02/Payment). Detail penuh: 02-decisions.md D49-D50.

---

Scorecard Service (maks 16)

Kode	Kriteria	Skor	Bukti / Alasan
J1	Independent Deployability	2	SP milik Payment terpisah bersih dari SP TransactionHistory (folder kode berbeda). DB-03 dipecah dari DB-02 supaya SV-03 punya siklus deploy sendiri, terpisah dari SV-02.
J2	Independent Scalability	1	Tidak ada data APM/traffic riil. Rasio handler Query:Command di folder TransactionHistory 13:3 (81% baca), tanpa caching.
J3	Fault Isolation (blast radius)	2	3 hop eksternal (AutoFinance/DistFinance, Email, SV-05) + 1 pelanggaran (V3, ke DB-06) terpetakan di activity-diagram-fxx.drawio halaman SV-03; kegagalan satu integrasi tidak merembet ke fitur lain.
J4	Team Ownership (Conway)	1	Belum ada tim khusus untuk Booking History, dan tidak ada testimoni eksplisit dari user soal tim SV-03 yang berdiri sendiri. Boundary domain juga masih tercampur dengan Payment (lihat J6), jadi skor tetap default lemah.
J5	Technology Divergence	0	Tidak ada kebutuhan stack berbeda.
J6	Bounded Context (DDD)	1	10-ddd-mapping.md BC-4 (“Ordering”) eksplisit menyatakan BC-4 bukan lagi mencakup pembuatan SO — cuma histori/Check Status/rating. Bounded context SV-03 masih mencampur 2 concern: histori (F01-F04, BC-4 murni) dan penulisan transaksi (F06, bagian BC-5 “Payment & Financing” bersama SV-02).
J7	Compliance / Security Isolation	0	Tidak ditemukan sinyal enkripsi/tokenisasi/audit di folder TransactionHistory — beda dari SV-02 yang punya FileEncryptionHelper untuk upload PO.
J8	Independent Lifecycle Data	1	Siklus hidup record Booking (F06) terikat erat ke proses Create Booking di SV-02 — belum benar-benar independen selama mekanisme SV-02→SV-03 belum diimplementasikan.
	TOTAL	8 / 16	Jatuh ke rentang ⚠️ TUNDA (6-9) — bukan lagi ✅ SPLIT.

Hard Blocker: HB1 = Tidak · HB2 = Tidak · HB3 = Tidak (migrasi EF — lihat DB7 — tidak menunjukkan co-change) Keputusan: ⚠️ TUNDA — cukup jadi modul dulu (bukan service jaringan terpisah), split lagi nanti kalau bukti J2/J4/J6/J7 bertambah & mekanisme SV-02→SV-03 (D28) sudah diimplementasikan.

---

Scorecard Database (maks 14)

Kode	Kriteria	Skor	Bukti / Alasan
DB1	Independensi Transaksi	1 ⚠️	Alur utama Create Booking tidak butuh transaksi ACID lintas-DB — SV-02 kirim payload, SV-03 commit sendiri. Tapi jalur admin RetryCreateSODO menjalankan satu transaksi yang menulis baik DB-03 (Booking/SO) maupun DB-02 (Saldo) sekaligus, tanpa rollback/kompensasi. Terikat ke Q20.
DB2	Independensi Foreign Key	2	FK-referensi bersifat read-only snapshot, konsisten dengan service lain — tidak ada FK inti yang putus.
DB3	Kohesi Aggregate	2	14 tabel kohesif seputar Booking/Sales/PO — satu unit “pesanan resmi”.
DB4	Single Writer	1	SP kembar (sp_Booking_Order_Update_Bank_Code dkk.) semuanya dipanggil dari RetryCreateSODOHelper — berarti RetryCreateSODO adalah admin arm SV-03 sendiri, bukan domain luar. Skor tetap 1 karena stp_cus_Booking_Order_Save (dipanggil dari Payment/SV-02) masih menulis langsung ke DB-03 — target arsitektur SV-02→SV-03 belum diimplementasi.
DB5	Master Data / Sync	0 ⚠️	stp_cus_dashboard_myTransaction (SV-11 F01 My Transaction, dan kemungkinan seluruh fitur SV-11 lain — Annual Summary, Hist Transaction Cost/Per Product/Success Count) query langsung tblT_Booking_Group/_Order/_Item, belum ada strategi replikasi/API/event sama sekali. SV-11 Dashboard sangat bergantung ke data histori transaksi ini, jadi ini sinyal warning eksplisit yang perlu perencanaan matang (event-driven/read-model) sebelum DB-03 benar-benar dipisah fisik.
DB6	Independensi Reporting	2	Versi terbaru (_alter_*) SP serving sp_Dashboard_GetPaid/GetUnPaid/GetWaitingForShipment/GetHistoryTransaction cuma FROM olap.agg_paid_daily/agg_unpaid_daily/agg_w_shipment_daily/agg_sales_daily — tidak ada JOIN langsung ke tblT_Booking_* di jalur serving. JOIN ke tblT_Booking_Order ada di SP populate/ETL (sp_PopulateDataHistoricalTransaction), bukan serving — itu memang wajib ada untuk membangun read-model, bukan pelanggaran. Beda dari SV-01 yang JOIN-nya ada di jalur serving (widget bypass read-model). Read-model SV-03 bersih di sisi konsumsi.
DB7	Stabilitas Skema (co-change)	2	Migrasi EF individual tidak ada yang menyentuh tabel DB-03 sejak baseline — pola sama bersihnya dengan SV-02.
	TOTAL	10 / 14	Tetap di atas ambang ≥9, tapi DB5=0 tetap jadi sinyal warning utama.

Hard Blocker: DHB1 = Tidak, tapi perlu verifikasi (Q20, sama dengan SV-02) · DHB2 = Tidak Keputusan: ✅ PISAH DATA — margin cukup longgar, tapi klarifikasi Q20 dan desain sync SV-11↔SV-03 (DB5=0) tetap wajib beres dulu.

---

Rekomendasi Akhir

Service: ⚠️ TUNDA (8/16, jatuh dari ambang SPLIT) · Database: ✅ PISAH DATA (10/14, margin wajar).

Menurut matriks Service×Data framework (§6B): kombinasi Service belum layak + Data layak dipisah = “(jarang) rapikan jadi modul dulu” — bukan kombinasi yang dibahas positif. Data DB-03 sudah cukup bersih untuk dipisah kalau nanti servicenya matang (read-model reporting sudah bersih, DB6=2), tapi DB5=0 (sync SV-11) tetap jadi PR nyata — jangan buru-buru jadi service jaringan terpisah sekarang.

Syarat sebelum dipertimbangkan split lagi:

1. 🔴 Klarifikasi Q20 (sama dengan SV-02) — status bisnis RetryCreateSODO/OrderHistory, termasuk risiko ACID lintas DB-02/DB-03 (DB1).
2. 🔴 Desain strategi sync SV-11→SV-03 (DB5=0, D25 belum diimplementasi) — SV-11 Dashboard butuh event-driven/read-model buat data histori transaksi, bukan raw SP query langsung, sebelum DB-03 benar-benar dipisah fisik.
3. Implementasikan mekanisme SV-02→SV-03 (D28, gRPC/event) — sampai ini beres, J6/J8/DB4 semua masih menunjuk SV-03 tercampur dengan domain Payment.
4. Tambah bukti J2 (traffic riil), J4 (peta tim nyata), J7 (kalau ada kebutuhan compliance yang belum ketemu).
5. Kalau SV-03 tetap mau dipisah dalam waktu dekat meski TUNDA, minimal jadikan modul internal yang rapi dulu (batas kode jelas, bukan lagi campur dengan Payment), baru pertimbangkan network boundary.