Tinjauan mudah tentang gagasan Rich Hickey di Clojure: kesederhanaan, imutabilitas, dan pengaturan bawaan yang lebih baik—pelajaran praktis untuk membangun sistem kompleks yang lebih tenang dan aman.

"type": "discount",
"code": "WELCOME10",
"percent": 10,
"valid_until": "2026-01-31"
}
\n\n**Mini-program dalam penyimpanan** (sulit berkembang):\n\njson
{
"type": "discount",
"rule": "if (customer.orders == 0) return total * 0.9; else return total;"
}
Kompleksitas menumpuk lewat keputusan-keputusan kecil yang secara lokal masuk akal (flag tambahan, cache, pengecualian, helper bersama) yang menambah mode dan keterkaitan.
Sinyal yang baik adalah ketika "perubahan kecil" membutuhkan edit terkoordinasi di banyak modul atau layanan, atau ketika reviewer bergantung pada pengetahuan tribal untuk menilai apakah perubahan itu aman.
Karena jalan pintas mengoptimalkan gesekan hari ini (waktu untuk dikirim) sambil mendorong biaya ke masa depan: waktu debugging, overhead koordinasi, dan risiko perubahan.
Kebiasaan berguna: saat tinjauan desain/PR, tanyakan: “Komponen bergerak atau kasus khusus baru apa yang diperkenalkan, dan siapa yang akan merawatnya?”
Default membentuk apa yang dilakukan insinyur saat berada di bawah tekanan. Jika mutasi adalah default, state bersama akan menyebar. Jika "in-memory baik-baik saja" adalah default, jejak dan keterlacakan menghilang.
Perbaiki default dengan membuat jalur aman menjadi jalur yang paling mudah: data immutable di batas modul, timezone/null/retry yang eksplisit, dan kepemilikan state yang jelas.
State adalah apa saja yang berubah seiring waktu. Yang sulit adalah perubahan membuka peluang ketidaksepakatan: dua komponen bisa memegang nilai “saat ini” yang berbeda.
Bug muncul sebagai perilaku tergantung waktu ("berjalan di mesin saya", gangguan produksi) karena pertanyaannya menjadi: versi data mana yang kita gunakan?
Imutabilitas berarti kamu tidak mengedit nilai di tempat; kamu membuat nilai baru yang mencerminkan pembaruan.
Secara praktis, ini membantu karena:
Mutabilitas bisa menjadi pilihan yang baik bila terkandung:
Aturan kunci: jangan biarkan struktur yang bisa dimutasi bocor melintasi batas di mana banyak bagian bisa membaca/menulisnya.
Race condition biasanya muncul dari data bersama yang bisa dimutasi dibaca lalu ditulis oleh banyak pekerja.
Imutabilitas mengurangi area koordinasi karena penulis membuat versi baru alih-alih mengedit objek bersama. Kamu masih perlu aturan untuk mempublikasikan versi saat ini, tapi data itu sendiri berhenti menjadi target yang bergerak.
Perlakukan fakta sebagai catatan append-only tentang apa yang terjadi (event), dan perlakukan “state saat ini” sebagai view yang diturunkan dari fakta itu.
Mulai kecil tanpa event sourcing penuh:
Simpan informasi sebagai data sederhana dan eksplisit (nilai), dan jalankan perilaku terhadapnya. Hindari menanamkan aturan eksekusi di dalam catatan yang disimpan.
Ini membuat sistem lebih mudah berkembang karena:
Pilih satu alur kerja yang sering berubah lalu lakukan tiga langkah:
Ukur keberhasilan lewat lebih sedikit bug flaky, radius ledakan perubahan yang lebih kecil, dan berkurangnya koordinasi hati-hati saat rilis.