Belajar Software Architecture and Design Patterns - DDD Strategic Design

#Pendahuluan

Setelah membandingkan gaya arsitektur (ep.17), pertanyaan berikutnya bukan "gaya apa" melainkan "di mana garis batasnya". Di sinilah Domain-Driven Design bagian strategic bekerja: sebelum satu class ditulis, kita sepakat bahasa, batas model, dan cara konteks-konteks itu saling berbicara. Episode ini adalah peta; episode berikutnya (tactical) adalah bangunannya.

#Konsep

#Ubiquitous Language

Bahasa bersama antara engineer dan domain expert — bukan jargon teknis yang diterjemahkan bolak-balik. Ketika expert bilang "produk dibooking stoknya", kode harus punya reserveStock(), bukan updateInventoryFlag(). Gejala bahasa retak: kalimat yang sama butuh arti berbeda di modul berbeda — sinyal kuat batas context salah tempat.

#Bounded Context

Model hanya SAH di dalam batasnya. Kata yang sama boleh bermakna beda lintas context — itu fitur, bukan bug:

Mencoba membuat satu class Product raja untuk ketiganya = model retak sejak hari pertama.

#Context Mapping

Bagaimana konteks saling berhubungan — tiap relasi punya nama dan strategi:

Shared Kernel   : subset model DIBAGI dua context (koordinasi ketat,
                  hemat tapi menggandung risiko)
Customer-Supplier: upstream melayani kebutuhan downstream (negosiasi)
Conformist      : downstream MENURUT total ke model upstream (hemat pikiran)
Anti-Corruption Layer (ACL): lapisan PENERJEMAH agresif - model luar
                  TIDAK BOLEH masuk mentah ke domainmu
Published Language/Open Host Service: kontrak publik resmi untuk banyak
                  konsumen (REST API schema, event schema)

#Event Storming Ringkas

Workshop temuan context versi Alberto Brandolini, dipadatkan:

1. Tempel semua domain event (orange): OrderPlaced, PaymentConfirmed, StockReserved...
2. Telusuri command (biru) & aktornya yang memicu tiap event.
3. Kelompokkan event yang HARUS konsisten bersama → kandidat aggregate (yellow).
4. Gumpalan agregat yang kohesif = kandidat bounded context — tarik "pita PVC" di antaranya.
5. Gambar panah relasi antar context → context map (pakai pola di atas).

#Real-World Implementasi

Studi kasus outline: pemetaan e-commerce + ACL payment gateway pihak ketiga.

// Struktur modular (ep.14) kini bernama CONTEXT:
@Module({ exports: [CatalogPublicApi] }) export class CatalogContext {}
@Module({ imports: [CatalogContext] })   export class OrderingContext {}
@Module({ providers: [BillingService] })  export class BillingContext {}
 
// ACL di infrastructure: model Midtrans BERHENTI di sini:
@Injectable()
export class MidtransPaymentGateway implements PaymentGateway {
  async charge(cmd: ChargeOrder): Promise<PaymentResult> {
    const raw = await this.http.post('/snap/v1/transactions', toMidtrans(cmd));
    return {                                    // translate eksplisit!
      status: mapStatus(raw.transaction_status), // 'settlement' -> Paid
      ref: raw.transaction_id,
    };
  }
}
// OrderingContext hanya kenal PaymentResult miliknya sendiri.

internal/
  catalog/     # model & service katalog (bahasa katalog)
  ordering/    # order, cart, checkout (snapshot harga sendiri)
  billing/     # invoice, pajak
  adapter/
    midtrans/  # func ToPaymentResult(raw midtransResp) ordering.PaymentResult
 
// ordering tidak import midtrans; main.go menyuntik interface:
orderingSvc := ordering.NewService(catalogRepo, midtrans.New(...))
// Ganti Xendit? tulis adapter baru, NOL perubahan di internal/ordering.

app/
  Domain/Catalog/    # Product, Category (model katalog)
  Domain/Ordering/   # Order, OrderLine (snapshot harga)
  Domain/Billing/    # Invoice, TaxRule
  Infrastructure/Payment/MidtransGateway.php  # implement Contract
 
// src/Domain/Ordering/Contracts/PaymentGateway.php - milik domain:
interface PaymentGateway { public function charge(ChargeOrder $c): PaymentResult; }
 
// AppServiceProvider - ACL terpasang di SATU titik:
$this->app->bind(PaymentGateway::class, MidtransGateway::class);

Ketiganya menegaskan aturan yang sama: context lain (atau vendor) hanya berkomunikasi lewat model penerjemahan yang KAMU kendalikan.

#Praktik

Target outline: event storming mini + gambar context map untuk studi kasus order management.

1. Daftarkan 15-20 domain event alur belanja:
   CartUpdated -> CheckoutStarted -> OrderPlaced -> StockReserved ->
   PaymentRequested -> PaymentConfirmed -> OrderPaid -> ShipmentCreated ...
2. Tandai mana event yang HARUS atomik bersama -> lingkari kandidat aggregate
3. Tarik batas context: minimal Catalog / Ordering / Billing / Shipping
4. Untuk tiap relasi antar context, PUTUSKAN polanya:
   Ordering<-Catalog : Customer-Supplier (via public API read-only)
   Ordering->Billing : Published Language (event OrderPaid)
   Ordering->Midtrans: Anti-Corruption Layer (WAJIB)
5. Gambar context map (draw.io/mermaid/excalidraw) + simpan sebagai
   docs/context-map.md DI REPO capstone-mu
6. Tulis catatan ADR singkat: kenapa batasnya begitu (3 kalimat)

[x] Setiap context punya definisi 'Product' yang BEDA dan sah
[x] Tidak ada context mengimpor model context lain secara langsung
[x] Relasi vendor selalu melewati ACL (grep: nol tipe vendor di domain)
[x] Context map tersimpan di repo dan cocok dengan struktur folder nyata

#Penutup

Rangkuman episode ini:

• Ubiquitous language mendeteksi batas yang salah; bounded context memberi setiap model wilayah sahnya.
• Context mapping menamai relasi antar context — dan ACL wajib untuk vendor eksternal.
• Event storming ringkas cukup untuk menemukan aggregate & context sebelum kode ditulis.

Episode 19 mengisi isi garis batas itu dengan objek yang benar: DDD Tactical Design — aggregate & aggregate root sebagai consistency boundary, entity vs value object, domain events, dan aggregate Order di ketiga stack. Sampai jumpa!