Skip to content
MyPertamina B2B Microservice

Customer Engagement Service — Scorecard Kajian

DB-05 · SV-05 — 29 tabel (dikoreksi dari 26, lihat catatan di bawah). Diagram: Helicopter View · Detail SV-05/DB-05.

Fitur: Payment Instruction, Customer/Bank Payment Mapping, Sales Group Position Mapping (baru), Banner, Mass Communication, Question & Question Category (pengganti FAQ), User Guide, Customer Support, Footer Link & Terms, Region

Scorecard Service (maks 16)

Section titled “Scorecard Service (maks 16)”
Kode Kriteria Skor Bukti / Alasan
J1 Independent Deployability 1 Tidak ditemukan bukti deploy independen — tidak ada data APM atau histori deploy. Tapi juga tidak ada coupling blocking ke kode service lain, beda dari SV-04.
J2 Independent Scalability 1 Tidak ada data APM. Sisi content (CustomerCenter) sekarang confirmed py command (Create/Update/Delete), bukan cuma read-only seperti dikira — tapi tetap tanpa caching, tanpa bukti profil beban berbeda.
J3 Fault Isolation (blast radius) 2 Tidak ada hop eksternal ditemukan — murni CRUD config (lihat activity-diagram-fxx.drawio SV-05). Tapi fault isolation di sini asimetris: SV-02/SV-03/SV-07/SV-08 semua bergantung baca ke SV-05 — kalau SV-05 down, banyak fitur consumer ikut terdampak.
J4 Team Ownership (Conway) 1 User ditanya langsung soal pemisahan tim config finansial vs content — jawabannya belum tahu, belum ada struktur tim yang jelas sekarang. Skor tetap default lemah, sama seperti service lain tanpa testimoni tim eksplisit.
J5 Technology Divergence 0 Tidak ada kebutuhan stack berbeda.
J6 Bounded Context (DDD) 1 ⚠️ 29 tabel membundel 2 domain berbeda (config finansial vs content), dan DDD BC-8 cuma mengenali sisi content. Sisi content sendiri sekarang punya bukti CRUD kuat (7 tabel, folder CustomerCenter), tapi itu justru mempertegas 2 domain ini tidak pernah berubah bersama sebagai satu unit.
J7 Compliance / Security Isolation 0 Tidak ditemukan sinyal enkripsi/tokenisasi/audit di folder CustomerCenter. Entitas config finansial (mis. TblMBank: cuma Bank/BankDesc/ID) juga murni deskriptif, tidak ada PII/nomor rekening.
J8 Independent Lifecycle Data 1 7 tabel content (UserGuide/Question/QuestionCategory/CustomerSupport/Banner/MassCommunication) sekarang confirmed py lifecycle sendiri (CreatedAt/CreatedBy/IsDeleted terkelola CRUD masing-masing). Sisanya (config finansial, 15 tabel) genuinely tanpa lifecycle apapun — bukan lagi “tidak jelas siapa nulis”, tapi dikonfirmasi statis/dikelola di luar aplikasi ini.
TOTAL 7 / 16 Tetap di rentang ⚠️ TUNDA (6-9).

Hard Blocker: HB1 = Tidak · HB2 = Tidak · HB3 = Tidak Keputusan: ⚠️ TUNDA — cukup jadi modul dulu (dengan 2 sub-modul internal jelas: config finansial vs content), split lagi nanti kalau ada driver bisnis nyata & bukti J1/J2/J4/J6/J7 bertambah.

Scorecard Database (maks 14)

Section titled “Scorecard Database (maks 14)”
Kode Kriteria Skor Bukti / Alasan
DB1 Independensi Transaksi 2 Tidak ditemukan kebutuhan ACID lintas batas — data config murni dibaca, tidak ada transaksi finansial yang butuh atomik bersama domain lain.
DB2 Independensi Foreign Key 2 FK-read oleh domain lain bersifat referensi kecil (Bank/Payment Method), konsisten pola snapshot service lain.
DB3 Kohesi Aggregate 1 ⚠️ 29 tabel bukan satu aggregate utuh — config finansial dan content tidak pernah berubah bersama sebagai satu unit konsistensi bisnis (lihat J6).
DB4 Single Writer 2 Tiap tabel yang py jalur tulis confirmed cuma py 1 penulis (CRUD-nya sendiri). Tabel tanpa jalur tulis (15 tabel finansial + KONV) bukan kasus multi-writer — genuinely belum/tidak ditulis aplikasi ini sama sekali.
DB5 Master Data / Sync 2 Tidak ditemukan masalah sync operasional terpisah dari temuan DB6 di bawah — data referensi kecil (Bank/Payment Method), dikonsumsi jarang berubah.
DB6 Independensi Reporting 1 FeatureAdmins/History/OrderHistory (GetOrderHistories/ExportOrderHistory) JOIN langsung ke tblM_Payment_Method/_Variant lewat sp_Revamp_Booking_Order_Get_Data_By_Sales_Org — dipanggil nyata meski nama file .sql.debug. Laporan histori booking masih bergantung JOIN langsung ke tabel DB-05. Arah fix: pola sama GetBriVaNumber (SV-02, kirim plant sebagai parameter ke stp_cus_Get_Rekening_Area, bukan JOIN tblT_Booking) — begitu jalur Admin ini dikonversi, skor berpotensi naik ke 2.
DB7 Stabilitas Skema (co-change) 1 Mayoritas tabel DB-05 (15 tabel finansial/footer/email, 2 tabel seed, KONV) 0 migrasi EF Core sama sekali — tabel legacy pra-EF, proxy co-change lewat migrasi tidak bisa diterapkan. Cuma segelintir tabel content (mis. tblM_User_Guide) yang punya migrasi individual bersih.
TOTAL 11 / 14 Turun dari 14/14, tetap di atas ambang ≥9.

Hard Blocker: DHB1 = Tidak · DHB2 = Tidak Keputusan: ✅ PISAH DATA — margin masih nyaman.

Temuan tambahan (pendalaman lanjutan)

Section titled “Temuan tambahan (pendalaman lanjutan)”
  • 🟢 7 tabel content confirmed py CRUD admin aktif & modern: tblM_User_Guide tblM_Question tblM_Question_Category tblM_Customer_Support tblT_Banner tblT_MassCommunication tblT_MassCommunication_Sales_Org — semua py folder FeatureAdmins/CustomerCenter/<Nama> (Create/Update/Delete) plus halaman AdminUI beneran.
  • 🟡 3 tabel FAQ lama kemungkinan dead code: tblM_Faq_Header/_Detail/_Category py SP tulis (sp_FAQ_Save) tapi 0 caller C# di manapun — kelihatan digantikan penuh oleh Question/QuestionCategory yang dipakai CustomerUI. Perlu konfirmasi user sebelum dianggap resmi mati.
  • 🔴 15 tabel finansial/footer/email — 0 jalur tulis genuinely dikonfirmasi (bukan cuma “belum ditemukan”): tblM_Bank tblM_Bank_Company tblM_Bank_Plant tblM_Payment_Method tblM_Payment_Method_Locale tblM_Payment_Method_Variant tblM_Payment_Term tblM_PaymentInstruction tblM_PaymentInstructionType tblM_PaymentInstructionTypeStep tblM_Rekening_Area tblM_Sales_Company tblM_Footer_Link tblM_Footer_Terms_And_Condition tblM_Email_Content.
  • ⚪ 2 tabel referensi statis, seed lewat migrasi: TblM_Region/TblM_VKGRP_Desc — dicek migrasi, isinya CREATE TABLE + puluhan INSERT INTO hardcoded. Dibaca (validasi Sales Group, dropdown Region), tidak pernah ditulis aplikasi.
  • ⚫ KONV — 0 referensi sama sekali di seluruh kode, bahkan tidak dibaca.
  • 🆕 2 tabel baru, belum berlabel service manapun: tblM_SalesEmailVKGRP/tblR_PositionSalesGroupMapping (folder FeatureAdmins/SalesGroupPositionMapping, transaksi ACID, integrasi Idaman via IUserPositionService) — konsep mirip/kemungkinan pengganti tblT_Sales_Org_Email_PIC yang sudah lama milik SV-05. Ownership belum resmi diputuskan.

Rekomendasi Akhir

Section titled “Rekomendasi Akhir”

Service: ⚠️ TUNDA (7/16) · Database: ✅ PISAH DATA (11/14, margin nyaman).

Menurut matriks Service×Data framework (§6B): kombinasi Service belum layak + Data layak dipisah = “(jarang) rapikan jadi modul dulu” — sama kombinasi dengan SV-03. Data DB-05 cukup bersih untuk dipisah kalau nanti servicenya matang, tapi jangan buru-buru jadi service jaringan terpisah sekarang.

Syarat sebelum dipertimbangkan split lagi:

  1. Rapikan jadi 2 modul internal yang jelas (config finansial vs content) di dalam SV-05 — kejelasan batas kode akan langsung menaikkan J6/DB3.
  2. Konfirmasi status 3 tabel FAQ lama (dead code atau masih dipakai) dan putuskan ownership tblM_SalesEmailVKGRP/tblR_PositionSalesGroupMapping (masuk SV-05 atau domain terpisah).
  3. Konfirmasi tblM_Company_Code/KONV — apakah boleh dianggap tabel mati dan dikeluarkan dari skema/dokumentasi.
  4. Tambah bukti J1/J2 (data deploy/traffic riil), J4 (peta tim nyata kalau ada rencana ke depan).
  5. Tutup gap DB6 — konversi FeatureAdmins/History/OrderHistory (sp_Revamp_Booking_Order_Get_Data_By_Sales_Org) ke pola “kirim plant sebagai parameter” (sama seperti GetBriVaNumber di SV-02), bukan JOIN langsung tblM_Payment_Method/tblT_Booking.