DDD Strategic Design — MyPertamina for Business

Versi bersih pasca-validasi domain expert (Juli 2026). Konsolidasi dari DDD-MyPertaminaB2B.md (pre-work) dan A1-Bounded-Context-Mapping.md (draft A1), setelah sesi validasi bersama domain expert. Klaim yang belum tervalidasi ditandai (open — workshop). Tujuan pemakaian: dasar perencanaan transformasi microservice.

Portal produksi:

Customer: https://apps.pertamina.com/mypertaminab2b/

Internal/Admin: https://apps.pertamina.com/mypertaminab2bInternal/

DDD
│
├── 1. Domain
├── 2. Subdomain
├── 3. Ubiquitous Language
├── 4. Bounded Context (termasuk Context Map & keputusan batas/SR)
├── 5. Proses Bisnis End-to-End (validasi bertahap bersama domain expert)
├── 6. Tactical Design — untuk perencanaan microservice
│   ├── 6.1 Entity & Aggregate (BC-4) · 6.7 (BC-5)
│   ├── 6.2 Domain Event
│   ├── 6.3 Value Object
│   ├── 6.4 Repository · 6.5 Domain Service · 6.6 Application Service
│   └── (dikerjakan per BC; BC-4 & BC-5 sebagai contoh utuh)
└── 7. Roadmap Ekstraksi Service (disetujui Jul 2026)

1. Domain

Perdagangan Energi B2B (Business-to-Business Energy Commerce) — hilir.

MyPertamina for Business adalah kanal digital Pertamina Patra Niaga tempat pelanggan bisnis menjalani seluruh siklus dagang tanpa perantara manual:

Menjadi pelanggan → mengetahui harga → memesan → membayar → menerima produk & dokumen tagihan → membina hubungan berkelanjutan.

Masalah bisnis yang diselesaikan: proses order B2B yang sebelumnya berjalan lewat email/telepon/sales visit — lambat, tak terlacak, rawan kesalahan harga — dipindahkan ke self-service yang tunduk pada aturan bisnis resmi (harga terpublikasi, batas kredit, dokumen legal, approval berjenjang).

Ketegangan struktural domain: portal bermimpi self-service, tetapi SAP ERP adalah pemegang kebenaran (pelanggan resmi, harga kontrak, SO/DO, piutang, invoice). Hampir semua peristiwa bisnis penting sesungguhnya terjadi di SAP; portal mengusulkan dan menyajikan.

Lini produk & segmen (per Sales Org) ✅ tervalidasi

Sales Org	Lini produk / segmen
2201	Retail — SPBU / lembaga penyalur
2202	Industrial & Marine Fuel — BBM industri & marine
2203	Aviation Fuel — avtur
2205	LPG Industry & Gas Product — termasuk gas domestik (DomGas)
2206	Petrochemical — petrokimia
3810	Lubricant — pelumas
1006	Trading

Bukti kode: enum MasterPriceType, TblMUserSpbu, ISaveDomGasService, penanganan khusus SalesOrg == "2201". Jejak NFR (TblMNfr*) dinyatakan di luar lingkup — diabaikan.

Aktor bisnis

Aktor	Sisi	Peran
Customer ✅	Eksternal	Pengguna eksternal pemilik akun Sold-To; memesan, membayar, mengunduh dokumen (portal customer)
Pelanggan e-Voucher (termasuk Agen Digital) ✅	Eksternal	Segmen tersendiri di setiap unit bisnis
User Business / Internal ✅	Internal	Seluruh pengguna internal — login via SSO IdAMan (portal internal). Mencakup peran Sales Admin, tim aviasi (sales admin/AM/conco-delco), petugas e-Voucher, administrator — disatukan sebagai “Internal” untuk saat ini
SAP	Sistem	Source of truth
Bank Mitra (AF/DF)	Eksternal	Menyetujui/menolak pembiayaan

Revisi Jul 2026: aktor “Viewer” dihapus; pembagian mendasar = Customer (eksternal) vs User Business/Internal (IdAMan).

2. Subdomain

Subdomain	Tipe	Alasan
Pemesanan (Ordering)	Core	Jantung nilai portal: mengubah niat beli menjadi SO resmi SAP secara mandiri
Pembayaran & Pembiayaan	Core	Aturan cash/credit/financing per profil pelanggan (+ saldo/deposit) = pengetahuan bisnis khas; menentukan cash flow
Operasi Aviasi	Core (segmen)	Kekhasan segmen: rezim harga sendiri (*menu Periodic Price: Posting & Domestic Contract Price* — satu-satunya harga terpublikasi portal ✅), catatan konsumsi uplift (real-time dari sumber SAP), kontrak internasional Conco-Delco. Pembelian tetap lewat alur Pemesanan umum ✅
e-Voucher	(open — workshop: klasifikasi)	Segmen pelanggan sendiri di setiap unit bisnis, termasuk Agen Digital; tim, tarif, dan kanal bayar (LinkAja) terpisah ✅
Keanggotaan Pelanggan (Onboarding & Compliance)	Supporting	Prasyarat semua proses core; nilainya kepatuhan, bukan pendapatan
Penagihan & Dokumen Fiskal	Supporting	Portal menyajikan dokumen buatan SAP/perpajakan (invoice, e-Faktur, Bupot PPh-22, DCN)
Katalog Produk	Supporting	Etalase tanpa harga ✅; produk sesungguhnya adalah material SAP
Hubungan & Layanan Pelanggan	Supporting	Pengumuman, banner, FAQ, rating
Identitas & Akses	Generic	Login/OTP/role — delegasi ke layanan korporat (SSO IdAMan, OTP PatraNiaga)
Notifikasi & Dokumen	Generic	Email, PDF, storage — commodity

✅ Revisi Jul 2026 — subdomain “Penetapan & Publikasi Harga” dihapus: domain expert menegaskan tidak ada harga periodik/economic/LPG untuk segmen non-aviasi. Satu-satunya harga terpublikasi adalah harga aviasi di menu Periodic Price → melebur ke Operasi Aviasi. Harga mengikat untuk semua segmen tetap lahir dari simulasi SAP (subdomain Pemesanan). Catatan teknis: endpoint/kode economic price & LPG price masih ada di codebase — kandidat konfirmasi dekomisioning.

3. Ubiquitous Language

✅ Tervalidasi: tim internal sehari-hari memakai istilah bisnis (sold-to, sales group, produk) — bukan kode SAP (KUNNR, VKGRP, MATNR). Kode SAP yang tampil sampai UI adalah kebocoran teknis yang harus dibersihkan lewat ACL.

Keanggotaan & identitas dagang

Sold-To ✅ — customer number perusahaan (nomor pelanggan resmi); “siapa yang membeli & berutang”
Ship-To ✅ — titik kirim milik Sold-To; satu Sold-To memiliki banyak Ship-To
Customer ✅ — pengguna eksternal portal (pemilik akun)
User Business ✅ — pengguna internal yang login menggunakan SSO IdAMan
Compliance ✅ — dokumen kebijakan aplikasi: privacy policy dan terms & conditions yang harus disetujui pengguna (koreksi Jul 2026 — bukan dokumen legal badan usaha)
Permintaan Sold-To / Ship-To ✅ — usulan pelanggan; dicek keberadaannya terhadap DB portal yang diturunkan dari SAP via scheduler sebelum diproses
RFO (Request for Offering) ✅ — form pra-login bagi calon pelanggan tanpa akun untuk meminta harga (saat ini hanya harga aviasi); bila di-approve Internal, PDF posting price dikirim — harga tidak pernah tampil langsung; satu email hanya boleh punya satu request pending (koreksi Jul 2026)
Relasi Akun–Sold-To ✅ — many-to-many: satu akun dapat mendaftarkan banyak Sold-To, dan satu Sold-To dapat dipakai di berbagai akun
Akun Utama (Main Account) ✅ — Sold-To yang diinput pertama saat registrasi menjadi akun utama
Switch Profile ✅ — customer memilih Sold-To aktif setelah login (konsekuensi relasi akun–Sold-To many-to-many); konteks seluruh transaksi & tampilan mengikuti Sold-To terpilih
~~SLA Konfirmasi~~ (dihapus — validasi Jul 2026: saat ini tidak ada SLA; enum UserConfirmationSlaStatus di kode adalah artefak teknis)

Organisasi penjualan

Sales Org — unit bisnis penjual (lihat tabel lini produk §1)
Sales Group — tim sales di bawah Sales Org; menentukan PIC & penerima email approval
Area Penjualan — Sales Org + saluran distribusi + divisi; keranjang & order selalu terikat satu area

Harga

Menu Periodic Price ✅ — satu-satunya kanal harga terpublikasi di portal; berisi Posting Price dan Domestic Contract Price, diakses pelanggan aviasi
Posting Price ✅ — harga avtur umum terpublikasi; istilah khusus aviasi (kode: GetAviasiPost*)
Domestic Contract Price ✅ — harga kontrak avtur per Sold-To, ditentukan tim aviasi (kode: GetAviasiContractDomestic*)
Aturan tampil harga ✅ — etalase/halaman produk tidak menampilkan harga; pelanggan bertemu harga hanya di menu Periodic Price dan di simulasi checkout, yang tampil sebagai total; tidak ada harga terpublikasi untuk segmen non-aviasi

Pemesanan

Keranjang — niat beli per area penjualan, belum mengikat
Bulk Buying ✅ — pemesanan massal via template unggah
Simulasi — penawaran mengikat dari SAP: harga final + ketersediaan + cek kredit; sekali pakai
Booking Order — pesanan portal bermasa-berlaku, menunggu dana/persetujuan
SO (Sales Order) — pesanan resmi tercatat di SAP; titik tak bisa kembali
DO (Delivery Order) — perintah penyerahan produk
Kontrak SA (Scheduling Agreement) — kontrak jangka panjang, kirim bertahap
Retry SO/DO — penanganan ulang order gagal terbentuk di SAP

Pembayaran & pembiayaan

TOP (Term of Payment) — bayar di muka (cash) atau tempo N hari (credit)
Batas Kredit — plafon utang; order tertahan bila terlampaui
Piutang Terbuka (AR Open) — tagihan berjalan belum lunas (kebenaran di SAP)
Verifikasi Pembayaran ✅ — pembayaran belum lunas sebelum terkonfirmasi; konfirmasi otomatis dari bank (H2H), upload bukti transfer sebagai fallback (koreksi Jul 2026 — bukan verifikasi manual)
Virtual Account (VA) ✅ — rekening tujuan transfer yang diterbitkan per pembayaran
AF/DF (Auto Finance / Distributor Financing) — order dibiayai bank mitra
Contract & Guarantee (Jaminan Kontrak) ✅ — agunan wajib bagi customer bermetode bayar credit (koreksi Jul 2026 — tidak ada istilah “Ijin Prinsip”)
Escrow ✅ — dana deposit customer (top-up) yang dipotong saat order Auto Collection (istilah resmi domain expert Jul 2026; kode: TblTSaldo, TblTTopUpSaldo, TblMRekeningAreaH2hautoColl)
Metode pembayaran ✅ — lima jalur checkout: Bank Transfer, Credit, Auto Collection (escrow), Auto Financing, Distributor Financing
FD Number (Financial Document) ✅ — nomor dokumen finansial; input opsional pada checkout Credit
NRD ✅ — tanggal credit approval; sistem memberi peringatan bila NRD < hari ini saat create SO (kode: IsNRDExpired)

Penagihan & fiskal

Proforma — tagihan pendahuluan sebelum invoice resmi ⚠️ (saat ini tidak digunakan — menu disembunyikan; validasi Jul 2026)
Invoice ✅ — tagihan resmi terbitan SAP; tersedia di portal begitu billing document terbit
Coretax ✅ — sumber file e-Faktur & Bupot PPh-22 yang disajikan portal
e-Faktur — faktur pajak elektronik
Bupot PPh-22 ✅ — bukti potong PPh pasal 22, diunduh pelanggan
Nota Debit/Kredit (DCN) — koreksi menambah/mengurangi tagihan

Aviasi

Uplift ✅ — catatan pengisian avtur ke pesawat (konsumsi); dibaca real-time dari sumber turunan SAP (linked server cntdimensional, tabel tbl_trx_aviation_sap_trx_zds_zsdpi05avi) — portal hanya memfilter & mengekspor, tidak menyimpan salinan. Pembelian avtur sendiri tetap lewat alur Pemesanan ✅
Conco-Delco — Contracting Company (yang ditagih) ≠ Delivering Company (yang mengisi)
PAP — komponen harga/biaya aviasi
Into-Plane ✅ — layanan pengisian ke pesawat (jasa, bukan barang)

e-Voucher ✅

e-Voucher — voucher prabayar untuk berbagai produk (bukan hanya avtur) ✅; pembeli adalah pelanggan e-voucher di setiap unit bisnis, tidak harus ber-kontrak
Tarif e-Voucher — tarif tersendiri, bukan posting price / harga kontrak aviasi

Akses

OTP Provider — kanal verifikasi: Email atau PatraNiaga Mobile Token
Blokir Sementara — akun dikunci sementara setelah kegagalan berulang

Istilah bermakna ganda (bukti batas context)

Istilah	Makna berbeda per context
Pelanggan	Badan usaha patuh dokumen (Keanggotaan) · orang yang login (Identitas) · debitur ber-plafon (Pembayaran) · audiens segmen (Hubungan) — butuh korelasi identitas User↔Sold-To, bukan tabel bersama
Order	Booking yang diperjuangkan jadi SO (Pemesanan) · objek yang harus dilunasi (Pembayaran) · sumber dokumen tagihan (Penagihan) · Sales Document VBELN (SAP)
Harga	Posting Price / Domestic Contract Price terpublikasi (Aviasi) · harga mengikat sekali-pakai hasil simulasi SAP (Pemesanan)

4. Bounded Context

Daftar (10 context)

#	Bounded Context	Capability satu kalimat	Klasifikasi

Penamaan (Jul 2026): nama BC diselaraskan dengan bahasa tim & menu portal (bahasa Inggris). Nomor BC tetap sebagai ID stabil.

Context map

flowchart LR
    BC1["BC-1 Customer<br/>Management"]
    BC3["BC-3 Product Catalog"]
    BC4["BC-4 Order ⭐"]
    BC5["BC-5 Payment &<br/>Financing ⭐"]
    BC6["BC-6 Billing &<br/>Tax Document"]
    BC7["BC-7 Aviation ⭐<br/>(menu Periodic Price:<br/>Posting & Domestic<br/>Contract Price)"]
    BC8["BC-8 Customer<br/>Engagement"]
    BC9["BC-9 Identity & Access"]
    BC10["BC-10 e-Voucher"]

    EXTSAP[("EXT SAP<br/>SD / FI / master data")]
    EXTIDAMAN["EXT IdAMan"]
    EXTOTP["EXT OTP Gateway"]
    EXTBANK["EXT Bank Mitra (AF/DF)"]
    EXTDJP["EXT Coretax<br/>(e-Faktur, Bupot PPh-22)"]
    EXTMBLAST["EXT mBlast"]
    EXTLINKAJA["EXT LinkAja"]

    BC4 -->|"CS"| BC3
    BC4 -->|"CS"| BC1
    BC5 -->|"CS"| BC4
    BC6 -->|"CS"| BC4
    BC6 -->|"CS"| BC7
    BC7 -->|"CS"| BC1
    BC8 -->|"CS"| BC4
    BC1 -->|"CS"| BC9
    BC10 -.->|"penebusan saat pengisian<br/>(open — dipetakan di workshop)"| BC7

    BC1 -->|"CF → ACL-01"| EXTSAP
    BC3 -->|"CF → ACL-01"| EXTSAP
    BC4 -->|"CF → ACL-02"| EXTSAP
    BC5 -->|"CF → ACL-03"| EXTSAP
    BC6 -->|"CF → ACL-04"| EXTSAP
    BC7 -->|"CF → ACL-05"| EXTSAP
    BC5 -->|"CS (ACL-06 disarankan)"| EXTBANK
    BC6 -->|"CF"| EXTDJP
    BC9 -->|"CF → ACL-07"| EXTIDAMAN
    BC9 -->|"CS · OHS"| EXTOTP
    BC8 -->|"CS"| EXTMBLAST
    BC10 -->|"CS"| EXTLINKAJA

Rendisi draw.io dari context map di atas — klik untuk memperbesar.

Perubahan penting vs draft lama: BC-2 Harga dihapus seluruhnya (tidak ada harga terpublikasi non-aviasi; menu Periodic Price milik BC-7) ✅ · BC-3 tidak mengonsumsi harga ✅ · BC-10 lahir dari pemecahan BC-7 (SR-05) ✅.

Keputusan batas (Suspicious Relationships) — status akhir sesi validasi

#	Pasangan	Verdict	Status
SR-01	Semua BC customer ↔ admin (satu Application + DB, dua deployable)	Tegakkan batas modul per BC dulu, pecah belakangan	OPEN — belum diputuskan pemangku kepentingan; bahan ADR
SR-02	Harga ↔ Aviasi	BC-2 Harga dihapus seluruhnya: menu Periodic Price (posting & domestic contract price) milik Aviasi; tidak ada harga terpublikasi non-aviasi	✅ Tervalidasi
SR-03	Pemesanan ↔ Pembayaran (status AF/DF tertanam di enum Booking Order)	Pertahankan terpisah; pisahkan state machine pembiayaan dari booking	Draft — konsekuensi desain A2/A3
SR-04	Keanggotaan ↔ Identitas	Korelasi identitas Akun↔Sold-To (relasi many-to-many ✅), bukan model bersama	Diperkuat Jul 2026
SR-05	Aviasi ↔ e-Voucher	Pecah: e-Voucher jadi BC-10	✅ Tervalidasi

Catatan untuk perencanaan microservice

Investasi arsitektur terbesar: Gerbang SAP (ACL). Semua batas ke SAP berstatus Conformist dengan ACL parsial — coupling belum dihilangkan, baru dipindahkan. Kualitas ACL menentukan kualitas seluruh portal.
±548 stored procedure memegang logika bisnis inti (pola stp_cus_*/stp_adm_* via Dapper) — penghalang utama ekstraksi service; strategi penarikan logika per-BC wajib masuk perencanaan.
Aviasi paling siap dipisah: proses beda arah, aktor sendiri, DB sudah terpisah (DB_ARPortal_Aviasi).
Catalog service bebas dari Pricing service — hasil koreksi BC-3 ✅. BC-3 Product Catalog = kandidat ekstraksi paling awal: read-only (mirror material SAP), mudah di-cache, Supporting (slice dari luar Core), dan memberi manfaat availability nyata — katalog tetap hidup meski layanan pemesanan down (hari ini belum terisolasi karena SR-01: satu Application layer + satu DB).
Kode tanpa fungsi bisnis (kandidat dekomisioning — konfirmasi sebelum migrasi, jangan ikut dipetakan ke microservice): (a) endpoint & handler economic price, LPG price, harga periodik non-aviasi — domain expert menyatakan konsepnya tidak ada, dan endpoint terbuka bagi semua customer ter-autentikasi; (b) query RFO Inmar (GetRFOInmarProduct/Location) — RFO dinyatakan khusus aviasi; (c) role Viewer & enum UserConfirmationSlaStatus — aktor Viewer dan SLA sudah dinyatakan tidak berlaku.
Dashboard bukan bounded context — ia komposisi tampilan lintas BC; di arsitektur target ditangani BFF / API composition layer (komponen teknis tanpa aturan bisnis), bukan service ber-domain sendiri.

5. Proses Bisnis End-to-End

Divalidasi satu per satu bersama domain expert (Juli 2026). Daftar proses: (1) Onboarding · (2) Harga · (3) Pemesanan · (4) Pembayaran & Pembiayaan · (5) Penagihan & Fiskal · (6) Aviasi · (7) e-Voucher · (8) Engagement.

Proses 1 — Onboarding (Create Account) ✅ tervalidasi

Calon customer membuka halaman Create Account (pra-login, portal customer)
→ mengisi SATU formulir sekaligus — tidak ada urutan antar isian:
   • Nama, E-mail, Password
   • Customer Number (Sold-To) → klik "Add Customer":
       - dicek SEKETIKA ke DB portal (mirror SAP via scheduler)
       - tidak ditemukan → DITOLAK LANGSUNG saat itu juga
       - boleh menambahkan lebih dari satu Sold-To
       - Sold-To yang diinput PERTAMA menjadi AKUN UTAMA (main account)
   • Centang compliance: Terms & Conditions + Privacy Policy
→ klik Create Account
→ email verifikasi terkirim ke customer (memastikan email valid)
→ approval oleh Internal
→ akun aktif, tertaut ke Sold-To yang didaftarkan

Varian: belum punya customer number → tautan "Make it now" → diarahkan KELUAR portal
        ke aplikasi Kemitraan Patra Niaga (https://kemitraan.patraniaga.com/) ✅

✅ Fakta batas (Jul 2026): pembuatan customer number / akuisisi pelanggan baru terjadi di luar portal (aplikasi Kemitraan). Portal hanya melayani yang sudah ber-customer-number — hulu perjalanan pelanggan bukan lingkup sistem ini. (Tautan “Partnership” di footer juga mengarah ke aplikasi eksternal.)

Fitur pra-login yang tersedia di halaman Create Account: customer support, RFO, dan introductory video.

Proses 2 — Harga (Aviasi) ✅ tervalidasi

Internal menginput harga aviasi:
   • Posting Price (harga avtur umum)
   • Domestic Contract Price (per Sold-To)
→ persetujuan internal
→ terbit PER PERIODE (BULANAN) di menu Periodic Price
→ customer aviasi melihat & mengunduh (PDF/Excel):
   • Posting Price: umum
   • Domestic Contract Price: sesuai Sold-To masing-masing

Jalur pra-login (RFO):
Calon pelanggan mengisi FORM RFO (bukan melihat harga langsung)
→ request masuk ke Internal
→ di-approve → PDF POSTING PRICE dikirim ke calon pelanggan
→ ditolak / dibiarkan → tidak ada dokumen terkirim
Aturan: selama masih ada request PENDING, email yang sama
        tidak dapat membuat request baru
Saat ini hanya harga aviasi yang dapat diminta via RFO

Aturan bisnis kunci:

Siklus terbit harga: bulanan.
RFO tidak pernah menampilkan harga di layar — dokumen posting price dikirim setelah approval Internal.
Anti-duplikasi RFO: satu email = satu request pending.

Aturan bisnis kunci:

Validasi Sold-To bersifat seketika terhadap mirror SAP — gerbang pertama sebelum apa pun diproses.
Urutan gerbang: email valid dulu, baru approval Internal — approval tidak berjalan untuk email yang tak terverifikasi.
Relasi Akun–Sold-To many-to-many sudah dimulai sejak registrasi (multi Sold-To dalam satu form); Sold-To pertama = akun utama.

Proses 3 — Pemesanan & Checkout ✅ tervalidasi (flow dari domain expert)

Kerangka umum:

Customer memilih produk (per area penjualan) → keranjang
   Varian: Bulk Buying via template unggah
→ checkout mengikuti METODE PEMBAYARAN (lima jalur, lihat bawah)
→ Booking & SO terbentuk (urutan bergantung jalur)
→ DO terbit — HANYA untuk kontrak SA
Kegagalan SO/DO → dua jalur pemulihan ✅:
   • antrean RETRY oleh Internal
   • tombol CHECK STATUS di history transaksi — customer memicu cek status
     & retry create SO sendiri (untuk AF/DF dan Bank Transfer)
Kedaluwarsa: booking dibatalkan otomatis setelah 3×24 JAM
             atau jika melewati delivery date

Aturan kunci (validasi Jul 2026):

Approval internal atas order: tergantung produk.
Masa berlaku booking: 3×24 jam atau hingga delivery date.
DO hanya untuk kontrak SA (scheduling agreement).
Upload PO wajib hanya untuk Credit dan Auto Collection.

Lima jalur checkout per metode pembayaran:

Jalur	Flow
Bank Transfer	Simulasi harga (SAP) → shopping summary & list produk → klik Pay Now → pop-up konfirmasi (tampil outstanding/overdue AR jika ada) → Ya → halaman payment instruction → Booking terbit saat Pay Now; SO terbit setelah pembayaran terverifikasi ✅
Credit	Input FD Number (opsional) → simulasi (SAP) → shopping summary + Credit Limit Summary + list produk → input PO Number & upload file PO (file bisa diunduh setelah berhasil) + pilih contract → klik Create SO → pop-up konfirmasi (peringatan bila: nilai simulasi > credit limit · NRD < hari ini · overdue AR) → Ya → receipt → sistem create SO → sistem create Booking
Auto Collection	Pilih bank → simulasi (SAP) → shopping summary + saldo escrow + Credit Limit Summary + list produk → input PO Number & upload file → klik Create SO → pop-up konfirmasi (peringatan sama) → Ya → receipt → sistem create SO → sistem create Booking
Auto Financing (AF)	Pilih bank → simulasi (SAP) → shopping summary + Credit Limit Summary + list produk → Cek Limit → summary auto financing facility → klik Create SO → pop-up konfirmasi (peringatan sama) → Ya → disbursement → sistem create Booking → approval bank ✅ → sistem create SO
Distributor Financing (DF)	Pilih bank → simulasi (SAP) → shopping summary + list produk → Cek Limit → summary distributor financing facility → klik Create SO → pop-up konfirmasi (outstanding/overdue AR jika ada) → Ya → disbursement → sistem create Booking → approval bank ✅ → sistem create SO

Varian Into-Plane (aviasi) (temuan kode — perlu konfirmasi domain expert): pembelian produk Into-Plane (material A040900041, tipe pembelian per-kuantitas atau per-nilai) mengikuti jalur checkout non-cash biasa, tetapi pada langkah create SO sistem memanggil Create Value Contract ke SAP (order type ZWK2, bernilai kontrak & bermasa berlaku; payer dari data IATA/SH aviasi). Status booking: ContractCreate → SOCreated / ContractFailed.

Pola tervalidasi ✅ — urutan pembentukan mengikuti kepastian dana:

Credit & Auto Collection: dana sudah pasti (termin/escrow) → SO dulu, baru Booking.
AF & DF: menunggu keputusan bank → Booking dulu → approval bank → SO (status WaitingApproval/Timeout/Rejected di kode hidup pada fase penantian ini).
Bank Transfer: Booking saat Pay Now → SO setelah pembayaran terverifikasi.

Proses 4 — Pelunasan Tagihan Credit (Open Billing) ✅ tervalidasi

Customer credit punya piutang berjalan → portal menarik AR Open dari SAP
→ customer memilih tagihan terbuka yang akan dibayar
→ membuat pembayaran → VIRTUAL ACCOUNT (VA) terbit ......... [Waiting for Payment]
→ customer transfer ke VA
→ KONFIRMASI OTOMATIS dari bank (H2H) ...................... [Paid - Need Verification]
→ .......................................................... [Completed]
   Fallback: bila status belum berubah, customer dapat UPLOAD BUKTI transfer
   Kedaluwarsa: 3×24 jam (sama seperti Bank Transfer) ....... [Payment Expired]
   atau dibatalkan .......................................... [Canceled]
Koreksi tagihan: Debit/Credit Note (DCN) menambah/mengurangi nilai

Menu “Credit” ✅ — hanya tampil untuk customer bermetode bayar credit; berisi:

List tagihan terbuka (AR Open dari SAP) beserta history pembayarannya
List Contract & Guarantee — hanya bisa dilihat (view-only; tidak ada pengajuan/perubahan jaminan dari portal) ✅

Aturan bisnis kunci:

Verifikasi pembayaran otomatis dari konfirmasi bank (H2H) — upload bukti transfer hanyalah fallback bila status tak kunjung berubah.
Pembayaran ke virtual account; masa berlaku 3×24 jam.
Visibilitas fitur mengikuti profil pembayaran customer: menu Credit tak terlihat oleh customer non-credit.

Proses 5 — Penagihan & Dokumen Fiskal ✅ tervalidasi (sebagian)

Billing document terbit di SAP
→ SEKETIKA ITU invoice tersedia diunduh customer di portal ✅
→ e-Faktur & Bupot PPh-22: FILE BERASAL DARI CORETAX ✅ — portal menyajikan
(Proforma: tidak digunakan — menu disembunyikan)

Nota debet/kredit (Debit Credit) ✅ — terbit di SAP; portal menarik daftarnya (ListDCNote) dan customer dapat mengaplikasikannya ke booking sebagai pengurang pembayaran (dicek agar tidak dipakai dua kali), dimonitor Internal. Posisi bisnisnya = instrumen pembayaran (Proses 4), bukan dokumen fiskal. (Catatan istilah: sebut “Debit Credit” — akronim “DCN” tidak dipakai bisnis.)

Aturan bisnis kunci:

Pemicu ketersediaan invoice = terbitnya billing document di SAP.
Dokumen pajak (e-Faktur, Bupot PPh-22) bersumber dari Coretax — portal tidak men-generate.

Proses 6 — Aviasi ✅ tervalidasi (sebagian)

Harga aviasi terbit (Proses 2: posting / domestic contract price)
→ PEMBELIAN avtur TETAP MELALUI PROSES 3 ✅
   (termasuk varian Into-Plane → Value Contract di SAP)
→ pengisian ke pesawat di bandara (UPLIFT) tercatat di SAP
→ menu Uplift Transaction: customer mengisi filter → EXPORT data ✅
   • data dibaca LANGSUNG DARI SUMBER saat diminta (query real-time via
     linked server ke DB dimensional turunan SAP:
     cntdimensional.dbo.tbl_trx_aviation_sap_trx_zds_zsdpi05avi)
   • portal tidak menyimpan salinan; tidak ada aksi lain selain export
→ penagihan & dokumen mengikuti Proses 4–5
Internasional: CONCO-DELCO — detail proses belum diketahui domain expert
               (open — konfirmasi tim aviasi)

Koreksi penting (Jul 2026): klaim lama “aviasi = transaksi dulu, tagih kemudian” tidak tepat — pembelian aviasi memakai alur checkout yang sama (Proses 3); kekhasan aviasi ada pada rezim harganya (posting/contract price), catatan konsumsi (uplift), dan struktur internasional (Conco-Delco).

Proses 7 — e-Voucher ✅ tervalidasi (sebagian)

Pelanggan e-voucher (termasuk Agen Digital, di setiap unit bisnis)
→ membeli e-voucher DARI PORTAL CUSTOMER ✅
   • e-voucher berlaku untuk BERBAGAI PRODUK — bukan hanya avtur ✅
   • kanal pembayaran: open (jejak kode: LinkAja & VA bank)
→ voucher terbit
→ voucher ditebus — mekanisme pencatatan penebusan: open
Internal: kelola tarif (rate & contract rate), kontrak pelanggan e-voucher
          (customer diambil dari sales org 2201/Retail), konfigurasi wilayah

Aturan bisnis kunci:

e-Voucher dibeli langsung dari portal customer; produknya lintas lini (bukan khusus avtur).
Detail kanal bayar & pencatatan penebusan belum diketahui domain expert → open question.

Proses 8 — Engagement ✅ tervalidasi

Internal menerbitkan konten:
   • Banner
   • Mass Communication → tampil sebagai POPUP di halaman dashboard,
     setelah customer login & memilih Sold-To (SWITCH PROFILE) ✅
   • User Guide & FAQ
→ Customer:
   • melihat banner & popup pengumuman
   • RATING: dari halaman history transaksi, ATAU langsung setelah transaksi
     (di halaman payment instruction / receipt / disbursement) ✅
   • Customer support = INFORMASI KONTAK saja (kontak per region + FAQ) —
     tidak ada ticketing ✅

Aturan bisnis kunci:

Mass communication bukan email blast — kanalnya popup dashboard pasca-login per Sold-To terpilih.
Rating melekat pada transaksi (booking), bisa diberikan segera atau dari riwayat.
Dukungan pelanggan bersifat informasional (kontak per region, FAQ), bukan tiket.

Menu	Isi	Bounded Context	Proses
Dashboard	Halaman utama pasca-login; popup mass communication tampil di sini setelah switch profile	BC-8 (konten) + ringkasan lintas BC	Proses 8
Profile — User Profile	Data akun pengguna	BC-9 Identity & Access	—
Profile — MFA Configuration	Pengaturan kanal OTP (Email / Mobile Token)	BC-9 Identity & Access	—
Profile — Change Password	Ganti kata sandi	BC-9 Identity & Access	—
Profile — Ship To	Daftar titik kirim milik Sold-To	BC-1 Customer Management	Proses 1 (varian)
Profile — Payment Method	Metode bayar yang tersedia bagi customer	BC-5 Payment & Financing	Proses 3–4
Profile — Statement of Account (SoA)	Laporan posisi akun/keuangan customer	BC-6 Billing & Tax Document	Proses 5
Profile — Privacy Policy	Dokumen kebijakan (compliance)	BC-1 Customer Management	Proses 1
Switch Profile	Memilih Sold-To aktif	BC-9 ↔ BC-1 (korelasi akun–Sold-To)	lintas proses
Categories / Katalog Produk	Katalog per kategori — tanpa harga	BC-3 Product Catalog	Proses 3 (awal)
Most Buying Product	Produk terlaris (kode: `GetTopProducts`)	BC-3 Product Catalog	Proses 3 (awal)
Last View Product	Produk terakhir dilihat (kode: `TblTProductLastView`)	BC-3 Product Catalog	Proses 3 (awal)
Search Produk	Pencarian + saran (kode: `SearchProducts`, `GetSearchSuggestions`)	BC-3 Product Catalog	Proses 3 (awal)
e-Voucher Registration	Registrasi pelanggan e-voucher — iframe LinkAja ✅	BC-10 e-Voucher	Proses 7
Cart	Keranjang per area penjualan	BC-4 Order	Proses 3
Credit	AR Open + history, Contract & Guarantee (view-only; khusus customer credit)	BC-5 Payment & Financing	Proses 4
Periodic Price	Posting & Domestic Contract Price (khusus customer aviasi)	BC-7 Aviation	Proses 2
Uplift Transaction	Filter & export data pengisian (real-time dari sumber)	BC-7 Aviation	Proses 6
Conco-Delco — Monitoring Invoice	Input/bulk upload invoice lintas entitas + referensi + switch vendor (role `AviasiCodelco`)	BC-7 Aviation	Proses 6
Transaction / History	Riwayat transaksi, SO/DO monitoring, dokumen (invoice, e-Faktur, Bupot), rating	BC-4/BC-6/BC-8	Proses 3, 5, 8

6. Tactical Design — untuk perencanaan microservice

Tujuan bagian ini bukan refactoring kode, melainkan perencanaan pemecahan: aggregate menentukan batas transaksi & kepemilikan data per service; domain event menjadi kontrak komunikasi antar service; sisanya pedoman internal service saat dibangun.

6.0 Kondisi kode hari ini (baseline)

Building block	Kondisi
Entity	~170 kelas anemic — cermin tabel DB, nol perilaku; aturan bisnis tinggal di 548 stored procedure
Value Object	Praktis tidak ada (hanya `Geolocation`)
Aggregate	Tidak ada — tabel dimanipulasi langsung
Domain Event	Rangka template ada (`DomainEvent`, `DomainEventService`) — nol event konkret
Repository	Tidak ada — `DbContext` langsung + `IStoreprocedureCall` (Dapper→SP)
Domain Service	Tidak ada
Application Service	✅ MediatR command/query handler (CQRS) — hidup & terstruktur per fitur

Kesimpulan: solution berkulit Clean Architecture, berjeroan database-centric. Rangka sudah benar — pekerjaan migrasi adalah mengisinya per bounded context.

6.1 Entity & Aggregate — BC-4 Order ✅ tervalidasi

Entity (objek ber-identitas & bersiklus hidup — pembawa aturan bisnis):

Entity	Identitas	Peran
Booking Order	`BookingNumber`	Aggregate root — memegang status & seluruh aturan hidup booking
Booking Group	Id (internal)	Anak Booking: area penjualan/ShipTo + nilai + `SoNumber`
Booking Item	Id (internal)	Anak Group: material, qty, harga, jadwal kirim
Cart Group	Id per area penjualan	Aggregate root keranjang
Cart Item	Id (internal)	Anak keranjang
Simulate Group	Id simulasi	Aggregate root — snapshot penawaran mengikat SAP
Simulate Item	Id (internal)	Anak simulasi
Dokumen PO	`PoNumber`	Aggregate root kecil — file PO terunggah

Prinsip: hanya aggregate root yang boleh direferensikan dari luar (by identity); anak-anaknya diakses lewat root-nya. Perilaku (Approve, MarkPaid, Expire, AttachDebitCredit) hidup di root — bukan di stored procedure.

Peta Aggregate:

Aggregate	Root & identitas	Anggota	Invariant (aturan yang dijaga)	Tabel yang dimiliki
Booking ⭐	Booking Order — `BookingNumber`	Booking Group → Booking Item; lampiran: nota debit/credit, jaminan kontrak, referensi PO, alasan reject	Transisi status (Created→…→SOCreated/Cancel per jalur bayar); kedaluwarsa 3×24 jam / delivery date; PO wajib untuk Credit & AutoColl; nota debit/credit tak boleh dipakai 2×; total header = Σ group; satu booking = satu pembayaran ✅; satu checkout = satu booking = satu SO ✅ (struktur multi-group di tabel = kelonggaran teknis, bukan praktik bisnis)	`TblTBookingOrder`, `TblTBookingGroup`, `TblTBookingItem`, `TblTBookingGroupCreditDebitNote`, `TblTBookingGroupKontrakJaminan`, `TblTBookingReject`, `TblTBookingOrderPaymentMethodVariant`, `TblMBookingNumber`
Keranjang	Cart Group — per area penjualan	Cart Item	Keranjang terikat satu area penjualan; tidak mengikat apa pun	`TblTCartGroup`, `TblTCartItem`
Simulasi	Simulate Group	Simulate Item	Snapshot sekali-pakai & immutable — harga mengikat dari SAP; hangus saat dipakai/kedaluwarsa	`TblTSimulateGroup`, `TblTSimulateItem`
Dokumen PO	PO — `PoNumber`	file terunggah	Terunggah utuh & dapat diunduh; direferensikan booking	`TblTPo`

Bukan aggregate — read model keluaran ACL SAP: TblTSalesOrder, TblTSalesOrderMaterial (cermin SO milik SAP, identitas VBELN).

Konsekuensi microservice: unit terkecil yang tidak boleh dipecah = Booking utuh (header+group+item satu transaksi ACID). Keranjang & Simulasi eventual terhadap Booking; ketiganya praktis satu Order Service.

6.2 Katalog Domain Event — BC-4 Order ✅ tervalidasi

Dipancarkan Order Service:

Event	Kapan (dari flow tervalidasi)	Konsumen
`BookingCreated`	Booking terbit (Pay Now di Bank Transfer; create SO di jalur lain)	Payment (siapkan VA/tagihan), Notifikasi
`BookingApproved`	Approval internal lolos (produk tertentu)	Payment, Notifikasi
`SOCreated` ⭐	SO resmi terbentuk di SAP — pivotal event	Billing/Dokumen, Engagement (rating), Notifikasi
`SOCreationFailed`	SO/DO gagal → antrean retry	Monitoring internal
`BookingExpired`	Lewat 3×24 jam / delivery date tanpa bayar	Payment (batalkan VA), Notifikasi
`ValueContractCreated`	Varian Into-Plane	Aviasi/Billing

Dikonsumsi Order Service:

Event	Dari	Reaksi
`PaymentVerified` (H2H bank)	Payment (BC-5)	Booking → Paid → create SO (Bank Transfer)
`FinancingApproved` / `Rejected` / `Timeout`	Payment (bank AF/DF)	Lanjut create SO / hentikan booking
`CustomerApproved`	Membership (BC-1)	Buka akses transaksi

Rekonsiliasi tarik-manual (bukan event) ✅: tombol Check Status di history transaksi — customer memicu pengecekan status & retry create SO sendiri untuk AF/DF dan Bank Transfer (kode: GetInquiryStatus). Dua jalur pemulihan: pull oleh customer + antrean retry Internal.

Catatan SR-03: dengan katalog ini, status pembiayaan (AutoFinWaitingApproval dkk.) tidak lagi menjadi status booking — booking cukup “menunggu dana” dan bereaksi terhadap event Payment Service. State machine gabungan hari ini terurai secara alami.

6.3 Value Object — kosakata di kontrak API & event

Konsep bernilai-sama (tanpa identitas) yang wajib konsisten di seluruh payload API/event antar service:

Value Object	Isi	Dipakai di
Uang (Money)	amount + currency (+ komponen pajak PPN/PPh/PBBKB bila perlu)	Semua kontrak nilai — hari ini `double` telanjang di mana-mana
AreaPenjualan	SalesOrg + DistChannel + Division	Keranjang, booking, produk — selalu bertiga, tak pernah sendiri
BookingNumber	format nomor booking	Identitas lintas service
Kuantitas	qty + SalesUnit (+ konversi DomGas)	Item keranjang/booking
StatusBooking	enum status per jalur bayar (tanpa status pembiayaan — lihat SR-03)	Order Service
PeriodeValiditas	validFrom–validTo	Value contract Into-Plane, harga

6.4 Repository — pintu keluar dari 548 stored procedure

Satu repository per aggregate root: IBookingRepository, ICartRepository, ISimulationRepository — memuat & menyimpan aggregate utuh, bukan per tabel.
Strategi strangler: tahap 1 — interface repository membungkus SP yang ada (pemanggil tak tahu bedanya); tahap 2 — implementasi diganti query milik service sendiri saat data sudah pindah ke DB service; SP pensiun bertahap.
Larangan sejak tahap 1: handler baru tidak boleh memanggil IStoreprocedureCall langsung untuk data yang sudah punya repository.

6.5 Domain Service — logika lintas aggregate DI DALAM satu service

Kandidat	Tanggung jawab
CheckoutPolicy	Aturan “urutan pembentukan mengikuti kepastian dana” per metode bayar (Credit/AutoColl: SO→Booking; AF/DF: Booking→approval bank→SO; Bank Transfer: Booking→bayar→SO)
BookingExpiryPolicy	3×24 jam / delivery date — dipakai job pembatalan harian

Bukan domain service: panggilan SAP (SimulateSO, CreateSO, CreateValueContract) dan bank (H2H, AF/DF) = port/ACL — gerbang eksternal, bukan logika domain.

6.6 Application Service — permukaan API tiap service

Handler MediatR yang ada hari ini = inventaris calon endpoint per service: folder FeatureCustomers/Carts|Payment|Transaction* → Order & Payment Service; Products → Catalog Service; dst. (selaras peta menu §5).
Target bentuk handler: orkestrasi tipis — muat aggregate via repository → panggil perilakunya → simpan → terbitkan event. Logika bisnis pindah ke aggregate/domain service, bukan tinggal di handler.

Urutan pengerjaan tactical per service yang diekstrak: aggregate & event dulu (sudah — untuk BC-4 & BC-5), lalu repository membungkus SP, lalu handler dikuruskan; VO menyusul di kontrak API. Pola ini direplikasi ke BC lain saat gilirannya tiba.

6.7 Peta Aggregate & Event — BC-5 Payment & Financing ✅ tervalidasi

Aggregate	Root & identitas	Anggota	Invariant	Tabel
Pembayaran Tagihan ⭐	`PaymentCode`	Daftar invoice yang dibayar (satu pembayaran boleh mencakup banyak invoice ✅ — dipilih di menu Credit); nota debit/credit; bukti transfer	Status Waiting → Paid-Need Verification → Completed / Expired / Canceled; 3×24 jam; nilai bayar = Σ invoice − nota; nota tak dipakai 2×	`TblTOpenBillingCredit`, `…Detail`, `…Crdr`
Buku Saldo Escrow	per `CustomerNo` (ledger append-only)	Entri masuk/keluar (top-up, disbursement AF tipe 3, debit order)	Saldo = Σ masuk − Σ keluar; saldo kurang → catat Pending Debet, dan customer tidak dapat bertransaksi sampai terselesaikan ✅	`TblTSaldo`, `TblTTopUpSaldo`, `TblTPendingDebet`, `TblMCustomerSaldo`
Pengajuan Pembiayaan	per booking + bank	Log request/response dua arah dengan bank (AF & DF)	Satu pengajuan aktif per booking; waiting/approved/rejected/timeout	`TblTAfReq`, `TblTDfReq`, `TblTAf/DfInvalidBooking`

Bukan aggregate: AR Open (milik SAP, via ACL) · master fasilitas/bank/metode bayar/instruksi (TblMCustomerAutoFin/DistFin, TblMBank*, TblMPaymentMethod*, TblMPaymentTerm, TblMPaymentInstruction*, TblMRekeningArea*) = konfigurasi.

Event yang dipancarkan Payment Service:

Event	Kapan	Konsumen
`PaymentCreated`	VA terbit	Order Service, Notifikasi
`PaymentVerified` ⭐	Konfirmasi H2H bank masuk	Order Service (lanjut create SO), Notifikasi
`PaymentExpired` / `PaymentCanceled`	3×24 jam lewat / dibatalkan	Order Service, Notifikasi
`FinancingApproved` / `Rejected` / `Timeout` ⭐	Keputusan bank AF/DF	Order Service, Notifikasi
`EscrowDebited` / `PendingDebetRecorded`	Debit order / saldo kurang	Order Service (blokir transaksi berikutnya bila pending debet ✅)

Dikonsumsi: BookingCreated (siapkan tagihan/VA) · BookingExpired (batalkan VA) · konfirmasi H2H & keputusan bank (dari sistem eksternal via ACL bank).

7. Roadmap Ekstraksi Service ✅ disetujui domain expert (Jul 2026)

Prinsip: naik tangga risiko — mulai dari yang read-only & mandiri, akhiri di core transaksional; ACL SAP dibangun sepanjang jalan.

Gelombang	Service	Alasan urutan	Prasyarat / catatan
0	(belum memecah) Modular monolith	Fondasi semua gelombang	Putuskan SR-01 → tegakkan batas modul per BC (larang referensi silang antar Feature); dekomisioning kode mati (economic/LPG price); mulai bangun Gerbang SAP (ACL)
1	Catalog Service (BC-3)	Read-only, bebas Pricing, manfaat availability langsung (katalog hidup walau order down); risiko minimal → tempat melatih pola (CI/CD, observability, kontrak API)	Perkenalkan BFF untuk komposisi Dashboard/History
2	e-Voucher Service (BC-10)	Paling mandiri: pelanggan sendiri, tarif sendiri, LinkAja sendiri; irisan tertipis dengan context lain	Jawab open question kanal bayar & penebusan
3	Aviation Service (BC-7)	DB sudah terpisah (`DB_ARPortal_Aviasi`); isi: menu Periodic Price, uplift export (passthrough DB dimensional), Conco-Delco	Konfirmasi pelaku Conco-Delco; akses linked server dari service
4	Order + Payment Service (BC-4 + BC-5, berpasangan)	Core terberat: konsentrasi SP tertinggi, ACL SAP kritis (simulate/create SO), integrasi bank, Hangfire	Dikerjakan setelah pola teruji; cetak biru = §6.1–6.7; komunikasi via event; rilis bergantian (Payment dulu — Order menunggu event-nya)
—	BC-1 Customer Management & BC-9 Identity & Access	Dipakai semua orang; korelasi akun–Sold-To N:M	Bertahan terlama di monolith / jadi layanan bersama
—	BC-6 Billing & Tax Document & BC-8 Customer Engagement	Read-mostly, risiko rendah	Menyusul kapan saja sesuai kapasitas

Daftar pertanyaan terbuka (workshop)

Klasifikasi BC-10 e-Voucher (Core/Supporting) + pemetaan relasinya (BC-7 saat penebusan, LinkAja, siapa pelanggannya secara master data).
Verdict final SR-01 (strategi modular monolith vs pecah langsung) — forum arsitektur/ADR.
Pemetaan owner bisnis per BC (validasi batas ≠ org chart).
Konfirmasi dekomisioning kode economic/LPG price (lihat catatan #5).
Mekanisme top-up escrow (temuan kode, perlu konfirmasi tim pembayaran): escrow = VA customer di bank mitra, diisi via transfer bank di luar portal; portal hanya membaca saldo (H2H). Saldo kurang saat order → pending debet dicatat. Khusus AF: disbursement bank tercatat otomatis sebagai top-up (tipe 3) per booking.
Into-Plane → Value Contract (temuan kode, perlu konfirmasi): order into-plane tidak membuat SO biasa melainkan Value Contract di SAP (CreateValueContract).
Conco-Delco (mekanisme terbaca dari kode; pelaku bisnisnya perlu konfirmasi tim aviasi): modul Monitoring Invoice di portal customer dengan CRUD penuh — invoice diinput/diunggah manual (bulk via template Excel), lengkap dengan data referensi (currency, tipe invoice, lokasi, material, unit, vendor) dan Switch Vendor. Satu-satunya fitur customer di mana invoice dibuat di portal, bukan ditarik dari SAP. Pemakainya role AviasiCodelco — siapa persisnya (pihak Delco? tim kontrak internasional?) belum terkonfirmasi.
e-Voucher: mekanisme pencatatan penebusan — konfirmasi ke tim e-voucher. (Sebagian terjawab: registrasi pelanggan e-voucher via iframe LinkAja di portal customer.)
Statement of Account (SoA): isi persis & sumber datanya (SAP?) — konfirmasi tim keuangan.

DDD Strategic Design — MyPertamina for Business

1. Domain

Lini produk & segmen (per Sales Org) ✅ tervalidasi

Aktor bisnis

2. Subdomain

3. Ubiquitous Language

Keanggotaan & identitas dagang

Organisasi penjualan

Harga

Pemesanan

Pembayaran & pembiayaan

Penagihan & fiskal

Aviasi

e-Voucher ✅

Akses

Istilah bermakna ganda (bukti batas context)

4. Bounded Context

Daftar (10 context)

Context map

Keputusan batas (Suspicious Relationships) — status akhir sesi validasi

Catatan untuk perencanaan microservice

5. Proses Bisnis End-to-End

Proses 1 — Onboarding (Create Account) ✅ tervalidasi

Proses 2 — Harga (Aviasi) ✅ tervalidasi

Proses 3 — Pemesanan & Checkout ✅ tervalidasi (flow dari domain expert)

Proses 4 — Pelunasan Tagihan Credit (Open Billing) ✅ tervalidasi

Proses 5 — Penagihan & Dokumen Fiskal ✅ tervalidasi (sebagian)

Proses 6 — Aviasi ✅ tervalidasi (sebagian)

Proses 7 — e-Voucher ✅ tervalidasi (sebagian)

Proses 8 — Engagement ✅ tervalidasi

Peta Menu Portal Customer → Bounded Context & Proses ✅ (Jul 2026)

6. Tactical Design — untuk perencanaan microservice

6.0 Kondisi kode hari ini (baseline)

6.1 Entity & Aggregate — BC-4 Order ✅ tervalidasi

6.2 Katalog Domain Event — BC-4 Order ✅ tervalidasi

6.3 Value Object — kosakata di kontrak API & event

6.4 Repository — pintu keluar dari 548 stored procedure

6.5 Domain Service — logika lintas aggregate DI DALAM satu service

6.6 Application Service — permukaan API tiap service

6.7 Peta Aggregate & Event — BC-5 Payment & Financing ✅ tervalidasi

7. Roadmap Ekstraksi Service ✅ disetujui domain expert (Jul 2026)

Daftar pertanyaan terbuka (workshop)