Belajar Software Architecture and Design Patterns - Layered vs Hexagonal vs Clean: Kapan Pakai Apa

#Pendahuluan

Empat episode terakhir memberi kalian tiga gaya arsitektur yang sering diklaim sebagai "yang benar". Episode ini berisi jawaban yang lebih dewasa: tidak ada yang benar secara universal — ada yang tepat untuk konteks tertentu. Menguasai pemilihannya adalah pembeda senior engineer dari penggemar pattern.

#Perbandingan

#Kompleksitas Biaya vs Benefit

Insight pentingnya: biaya hexagonal/clean bersifat upfront, manfaatnya tertunda. Startup yang akan pivot dalam 6 bulan membayar ceremony untuk manfaat yang tak sempat dinikmati.

#Ukuran Tim & Domain Complexity Matrix

Tiga pertanyaan penentu:

1. Berapa aturan bisnis yang punya invarian mahal? Banyak → clean/hex; sedikit → layered cukup.
2. Seberapa sering detail teknis berubah? DB/vendor/framework berganti → ports melindungi; stabil → abstraksi ekstra sia-sia.
3. Berapa besar tim & rotasinya? Tim besar/rotasi cepat → struktur eksplisit + arch test bernilai; tim 3 orang yang saling kenal → konvensi ringan.

#Studi Kasus

#Tiga Konteks, Tiga Keputusan

Startup MVP (5 dev, produk belum terbukti): Layered/modular sederhana. Service-repository + DTO disiplin (ep.8–10) sudah melindungi cukup. Fokus energi pada validasi pasar, bukan folder. Strangler-friendly: modular ringan memudahkan refactor nanti.

Fintech core (30+ dev, uang nyata, audit): Hexagonal/Clean penuh + DDD (ep.18–19). Invarian ledger tak boleh dilanggar → rich aggregate dengan arch test. Ports memungkinkan swap provider payment & simulasi regulator. Ceremony di sini adalah asuransi.

Produk besar multi-domain (e-commerce raksasa): Modular monolith dengan internal style bebas per modul — modul catalog cukup layered, modul ordering hexagonal+CQRS. Standar lintas-modul hanya satu: public API & event contract (ep.14).

#Praktik

Target outline: tulis ADR (Architecture Decision Record) memilih gaya untuk skenario given.

A. Marketplace UMKM: 4 dev, fitur = katalog+order+pembayaran via Midtrans,
   runway 9 bulan.
B. Core banking lending: 40 dev, aturan bunga kompleks + audit regulator,
   umur target 10 tahun.
C. Internal HR tools: 3 dev, CRUD dominan, 200 user internal.

# ADR 0001: Gaya Arsitektur [nama project]
 
## Status
Proposed | Accepted | Superseded oleh ADR-xxx
 
## Konteks
Tim: N dev. Domain: [deskripsi + invarian utama].
Umur rencana: X tahun. Teknologi: [stack]. Volume CI: Y run/hari.
 
## Pilihan yang Dipertimbangkan
1. Layered modular - pro/kontra singkat
2. Hexagonal penuh - pro/kontra singkat
3. Hybrid per modul - modul mana gaya apa
 
## Keputusan
[Satu kalimat tegas.]
 
## Alasan
[Terhubung ke fakta konteks - bukan selera.]
 
## Konsekuensi
Positif: ... Negatif/diterima: ... Mitigasi: ...
Review kembali saat: [trigger konkret, mis. tim > 12 orang]

Kriteria penilaian latihan kalian (self-check):

[x] Keputusan bisa DITOLAK orang lain lewat argumen konteks (bukan selera)
[x] Ada trigger review eksplisit (kapan ADR ini usang)
[x] Konsekuensi negatif DIJUJURI, bukan disembunyikan
[x] Hybrid diperbolehkan - tidak semua-or-nothing

#Penutup

Rangkuman episode ini:

• Tidak ada arsitektur universal: cocokkan gaya pada kompleksitas domain, umur sistem, dan ukuran tim.
• Hybrid pragmatis adalah jawaban realistis: batas antar modul konsisten, gaya dalam modul mengikuti kebutuhan.
• ADR mengubah keputusan arsitektur menjadi artefak yang bisa direview, ditolak, dan dipelajari.

Episode 18 masuk dunia DDD bagian pertama: Strategic Design — ubiquitous language, bounded context, context mapping, dan event storming ringkas untuk studi kasus order management. Sampai jumpa!