Pemetaan DDD System Analys dengan Kajian Teknis
Perbandingan DDD Strategic Design (System Analyst, divalidasi domain expert) dengan kajian teknis kita (Overview Kajian Scorecard, evidence kode/SP). Dua metodologi berbeda: DDD = batas bisnis (divalidasi manusia), kajian kita = evidence kode (scorecard J1–J8/DB1–DB7). Tidak ada keputusan yang diubah di sini — murni pemetaan + pencatatan gap/tensi untuk ditindaklanjuti tim.
Tabel pemetaan: 10 Bounded Context ↔ SV-xx/DB-xx
Section titled “Tabel pemetaan: 10 Bounded Context ↔ SV-xx/DB-xx”⚠️ Update D29 (2026-07-20): kajian teknis sekarang memecah BC-1/BC-9 jadi 2 service terpisah
(SV-12 Customer / SV-09 Account) — persis rekomendasi DDD SR-04 di tensi T2 (lihat di bawah). Tensi T2
resmi ditutup, kajian teknis mengikuti arah DDD.
| BC | Nama (DDD) | Kapabilitas | Service/DB-xx |
|---|---|---|---|
| BC-1 | Customer Management | Sold-To/Ship-To, RFO pra-login, compliance (T&C/Privacy) | SV-12/DB-12 (sebagian) — ✅ dipisah dari Identity sejak D29 |
| Dihapus oleh tim DDD sendiri | — | ||
| BC-3 | Product Catalog | Katalog tanpa harga | SV-01/DB-01 |
| BC-4 | Order | Cart → Simulasi → SO | SV-01(Cart) + SV-02(Simulate) + SV-03(Booking/SO)/DB-01+DB-02+DB-03 |
| BC-5 | Payment & Financing | Cash/credit/AF-DF/saldo | SV-02/DB-02 (modul internal, D5) |
| BC-6 | Billing & Tax Document | Invoice, e-Faktur, Bupot PPh-22, DCN | SV-06(Invoice/SoA/EFaktur/Bupot, evidence besar D29) + SV-02→SV-05(DCN) + SV-08(DCN) |
| BC-7 | Aviation | Periodic Price, Uplift, Conco-Delco | SV-10/DB-10+DBAV + SV-07/DB-07 (Periodic Price) |
| BC-8 | Customer Engagement | Banner, Mass Comm, FAQ, rating | SV-05/DB-05(konten, D12) + SV-03/DB-03(rating) |
| BC-9 | Identity & Access | Auth Customer (OTP) + Internal (SSO) | SV-09/DB-09 — ✅ dipisah dari Customer Management sejak D29 |
| BC-10 | e-Voucher | Jual/tebus voucher | SV-04/DB-04 |
Cakupan ringkas: ✅ tercover penuh — BC-4, BC-5, BC-8, BC-9, BC-10. ⚠️ tercover sebagian (ada gap, lihat di bawah) — BC-1, BC-3, BC-6, BC-7.
Gap — ada di DDD (nyata secara bisnis), belum pernah discan di kajian teknis
Section titled “Gap — ada di DDD (nyata secara bisnis), belum pernah discan di kajian teknis”Bukan salah taruh service — memang belum pernah masuk radar kajian kode sama sekali (dicek: 0 hasil untuk semua istilah ini di seluruh source kajian teknis).
| # | Fitur/entitas | BC asal | Kenapa belum ke-scan |
|---|---|---|---|
| G1 | Ship-To management (menu “Profile — Ship To”) | BC-1 | SV-12 belum pernah discan sampai level menu; fitur SV-12 masih provisional (Q18) |
| G2 | ✅ DITUTUP (D31) SearchProducts, GetSearchSuggestions) |
BC-3 | Dianggap bagian F01 Product Catalogue (filter produk), bukan fitur terpisah — tidak perlu di-scan detail sendiri |
| G3 | ✅ DITUTUP (D29) — Bupot PPh-22 (bukti potong PPh psl 22, sumber Coretax) | BC-6 | Ternyata ada di kode — folder FeatureCustomers/Transaction/GetBupotPPh22*, ditemukan D29 saat evidence SV-06 diperluas. |
| G4 | Coretax sebagai sistem eksternal | BC-6 | Sebagian ditutup D29 — EFaktur (SV-06) kemungkinan sumbernya Coretax, tapi endpoint aslinya belum ditelusuri. Belum masuk daftar integrasi eksternal kajian teknis. |
| G5 | Uplift Transaction (export real-time linked server cntdimensional.dbo.tbl_trx_aviation_sap_trx_zds_zsdpi05avi) |
BC-7 | SV-10 sengaja tidak discan detail (“di luar cakupan analisis”) |
| G6 | Conco-Delco Monitoring Invoice CRUD + Switch Vendor (role AviasiCodelco, bulk upload invoice) |
BC-7 | Sama seperti G5 — SV-10 cuma punya 2 fitur generik, jauh lebih tipis dari yang DDD deskripsikan |
Rekomendasi: G1 murah untuk ditutup (scan cepat folder Account untuk Ship-To) — G2 sudah ditutup. G3–G6 lebih besar — G5/G6 baru masuk akal begitu Aviasi (SV-10) jadi prioritas scan, karena sekarang sengaja di luar cakupan.
Tensi arsitektur — 2 kesimpulan berbeda, sama-sama valid untuk sudut pandangnya
Section titled “Tensi arsitektur — 2 kesimpulan berbeda, sama-sama valid untuk sudut pandangnya”Bukan berarti salah satu salah — beda basis (evidence kode saat ini vs desain target hasil validasi bisnis). Dicatat supaya tidak diasumsikan salah satu “menang” begitu saja.
| # | Topik | Keputusan kajian teknis | Usulan DDD | Catatan rekonsiliasi |
|---|---|---|---|---|
| T1 | Payment vs Booking | D5: hard-blocker veto, Payment tetap modul internal Booking (8 handler multi-writer, butuh ACID bersama) | BC-5 service terpisah dari BC-4, komunikasi via domain event (PaymentVerified, FinancingApproved) |
Kemungkinan bukan kontradiksi — DDD menyediakan blueprint saga yang D5 syaratkan sebelum pisah. Bukan “boleh pisah sekarang”. |
| T2 | Identity vs Customer Management | ✅ DITUTUP (D29): kajian teknis awalnya (D21) menggabung 1 service karena junction tblM_User_Customer butuh 1 transaksi ACID — dibalikkan sebagian di D29, sekarang dipecah SV-09 Account + SV-12 Customer (junction ikut SV-12, kekhawatiran ACID belum sepenuhnya terselesaikan) |
SR-04: BC-1 & BC-9 tetap dua BC terpisah, cuma berkorelasi (Akun↔Sold-To many-to-many) | Kajian teknis sekarang mengikuti arah DDD — tapi implementasi ACID lintas SV-09/SV-12 masih perlu dipikirkan sebelum ekstraksi fisik. |
| T3 | Dashboard: service atau BFF? | SV-11 service sendiri, DB-11 NoSQL — preseden pola olap+Hangfire admin sudah ada di kode |
Poin 6: “Dashboard bukan bounded context” — komposisi lintas BC, ditangani BFF/API composition layer | Dua pola valid untuk masalah sama (materialized read-model vs live composition), konsekuensi implementasi beda jauh. |
| T4 | Cart menempel di mana? | SV-01 (bareng Catalog) | BC-4 Order (bareng Simulate/Booking/SO), BC-3 Catalog tanpa Cart | Alasan DDD: Cart = “niat beli”, bagian alur Order bukan katalog. |
| T5 | Status SV-07 (Pricing) | Service ke-7 kita, 8 tabel, evidence kuat | Periodic Price = murni bagian BC-7 Aviation (bukan service sendiri); economic/LPG price = kode mati (domain expert) | Paling actionable — lihat catatan khusus di bawah. |
Catatan khusus T5 — SV-07 makin dipertanyakan
Section titled “Catatan khusus T5 — SV-07 makin dipertanyakan”Domain expert menegaskan tidak ada harga periodik/economic/LPG non-aviasi, dan RFO Inmar dinyatakan khusus
aviasi juga. Sebagian besar isi SV-07 (Browse Periodic Price umum/LPG, Browse Economic Price MFO/MBC)
yang dipetakan dari bukti kode nyata (admin CRUD via EF/LINQ, tabel TblM_Periodic_Price_Economic_*)
kemungkinan kode yang ada tapi tidak dipakai bisnis — bukan gap, tapi tensi “kode hidup vs kebutuhan bisnis
mati”. Kalau dikonfirmasi, SV-07 kemungkinan melebur ke SV-10 (Aviasi) untuk sisa Posting/Domestic Contract Price,
sisanya jadi kandidat dekomisioning — bukan tetap jadi service ke-7 sendiri.
Convergensi — saling menguatkan (tidak perlu tindak lanjut, cukup dicatat)
Section titled “Convergensi — saling menguatkan (tidak perlu tindak lanjut, cukup dicatat)”| Temuan | DDD | Kajian teknis |
|---|---|---|
| eVoucher paling siap dipisah | SR-05, alasan tim beda | Alasan Conway’s Law identik — lihat SV-04 |
| Aviasi kandidat ekstraksi awal | §7 Wave 3 | Kandidat ekstraksi awal juga, dengan 1 catatan koreksi (lihat di bawah) |
| SAP = source of truth, butuh ACL | Tema sentral | Berulang di semua service |
| ~550 SP = penghalang ekstraksi | “±548 SP” | 557 file SP |
| Proforma sudah mati | “menu disembunyikan” | DB Aviasi: “menu SO Proforma sudah tidak ada di customer” |
Lihat juga
Section titled “Lihat juga”Pemetaan Accenture — pemetaan sumber ketiga (slide to-be Accenture), termasuk tensi Integration Gateway SAP terpusat yang didukung DDD maupun Accenture tapi belum diadopsi kajian teknis.