Product Catalogue, Cart Service — Scorecard Kajian

DB-01 · SV-01 — 25 tabel dimiliki (MARA, MARC, MVKE, T001W, T151, tblT_Cart_Group, tblT_Cart_Item, tblM_Sales_Org*, dst). Diagram: Helicopter View · Detail SV-01/DB-01.

Kode fitur Fxx di bawah mengacu ke halaman Detail SV-01 (F01 Product Catalogue, F02 Most Buying, F03 Last View Product, F04 Download Bulk Buying Template, F05 Request Extend Product, F06 Add To Cart, F07 Update Cart Item, F08 Delete Cart Item).

---

Scorecard Service (maks 16)

Kode	Kriteria	Skor	Bukti / Alasan
J1	Independent Deployability	2	DB-01 (25 tabel) sepenuhnya terpisah dari DB-02. Perubahan katalog produk / cart tidak pernah menyentuh logika Booking.
J2	Independent Scalability	⚠️ 1	Provisional — belum ada data traffic/APM riil. Skor tetap diberi bobot lemah berdasar fakta struktural alur UX, bukan angka traffic: fitur SV-01 (F01-F04: Product Catalogue, Most Buying, Last View, Search) secara desain di-browse berkali-kali per sesi sebelum user checkout satu kali.
J3	Fault Isolation (blast radius)	2	Seluruh fitur berhenti di DB-01 atau layanan pendukung (Blob/Email/SAP kondisional) — tidak ada panggilan sinkron ke SV-02. Booking yang sudah ada tetap jalan walau SV-01 down.
J4	Team Ownership (Conway)	⚠️ 1	Belum ada tim khusus yang menangani semua fitur terkait Product Catalog, tetapi dengan boundary context yang jelas, sangat memungkinkan untuk ownership dan maintain/support dan deployment berdiri sendiri, tanpa melibatkan tim lain yang tidak berkepentingan.
J5	Technology Divergence	0	Tidak ada kebutuhan stack berbeda — sama-sama .NET 8 + SQL Server seperti monolith keseluruhan. Tidak ada driver teknologi untuk pisah.
J6	Bounded Context (DDD)	2	25 tabel dimiliki bersih membentuk domain “Katalog Produk & Keranjang”. Ini juga sejalan dengan analisis DDD, dimana service ini meng-cover BC-3 Product Catalog, dan BC-12 Cart.
J7	Compliance / Security Isolation	0	Tidak ada bukti kebutuhan isolasi compliance/security spesifik untuk domain ini.
J8	Independent Lifecycle Data	2	Cart bersifat ephemeral (item dihapus otomatis begitu checkout sukses, lewat pendekatan event-driven yang disepakati), sementara Product Catalogue adalah data referensi read-mostly. Siklus hidup keduanya jelas berbeda dari data Booking yang permanen & auditable.
	TOTAL	10 / 16

Hard Blocker: HB1 = Tidak · HB2 = Tidak · HB3 = Tidak

Keputusan: ✅ SPLIT

---

Scorecard Database (maks 14)

Kode	Kriteria	Skor	Bukti / Alasan
DB1	Independensi Transaksi	2	Product Catalogue/Cart tidak pernah butuh transaksi ACID bersama Booking; nilai master disalin ke record transaksi saat Booking dibuat.
DB2	Independensi Foreign Key	2	FK-referensi (KNA1, KNVP, KNVV, ADRC, ADR6, dst) seluruhnya bersifat read-only snapshot, bukan live FK constraint, tidak ada FK inti yang “putus”.
DB3	Kohesi Aggregate	2	25 tabel DB-01 (MARA/MARC/MVKE/T001W/T151, Cart_Group/Item, Sales_Org*, Material_*) secara data berubah bersama sebagai satu unit “katalog + keranjang”. Ketika ada transaksi di service ini, tidak mengharuskan untuk update data di service lain.
DB4	Single Writer	2	Semua table dalam DB-01 masih ditulis oleh service yang sama, baik itu penambahan produk lewat sync SAP ataupun maintain deskripsi/product image dari sisi Admin.
DB5	Master Data / Sync	2	Service lain yang membutuhkan data dari DB-01 akan melakukan snapshot ketika transaksi terjadi.
DB6	Independensi Reporting	0	Reporting diambil tugasnya oleh service lain (Dashboard) untuk membuat data laporan penjualan harian — namun read-model ini masih JOIN langsung ke tabel DB-01 (MARA) saat populate maupun serving, belum lepas penuh.
DB7	Stabilitas Skema (co-change)	2	Perubahan skema table di dalam DB-01 stabil, tidak perlu diperbaharui berbarengan dengan skema domain lain.
	TOTAL	12 / 14

Hard Blocker: DHB1 = Tidak · DHB2 = Tidak Keputusan: ✅ PISAH DATA (margin lebih nyaman dari Scorecard Service — lihat catatan kerapuhan J2 di atas)

---

Rekomendasi Akhir

FULL MICROSERVICE (DB sendiri) — SPLIT (service) + PISAH DATA (database). ⚠️ Tapi TOTAL Service kini persis di ambang bawah (10/16, ambang ≥10) — lihat catatan kerapuhan di bawah.

Syarat sebelum eksekusi: Dapatkan data APM/traffic riil untuk memastikan J2 — satu-satunya kriteria yang skornya masih berbasis argumen kualitatif (pola browse-berkali-kali vs checkout-sekali), bukan angka traffic terukur.

⚠️ Catatan kerapuhan keputusan: TOTAL Service persis di ambang bawah ✅ SPLIT (10/16, ambang ≥10) — J2 (skor 1) adalah satu-satunya kriteria yang menahan total di atas ambang tanpa didukung data traffic riil. Kalau nanti APM didapat dan ternyata tidak mendukung, skor J2 bisa turun ke 0 dan keputusan berbalik ke ⚠️ TUNDA (Total 9). Scorecard Database jauh lebih stabil (12/14, margin nyaman dari ambang ≥9). Rekomendasi SPLIT untuk SV-01 sebaiknya dibaca sebagai “layak, tapi tervalidasi minimal di sisi Service — cek data APM riil sebelum commit sepenuhnya ke arsitektur ini.”