Evolving Design Decisions, Menuju Desain yang Tumbuh Bersama Pengetahuan

Di artikel-artikel sebelumnya, kita belajar bahwa domain model itu hidup. Ia berkembang seiring perubahan bisnis dan pemahaman tim.

Tapi bukan hanya model domain yang perlu berevolusi. Keputusan desain dan arsitektur pun harus mengikuti — karena yang kita tahu hari ini belum tentu benar besok.

“Good design decisions are not permanent. They are just good for now.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Inilah inti dari bab ini: desain yang baik adalah desain yang bisa tumbuh bersama waktu dan pengetahuan.

Mengapa Desain Harus Berevolusi

Kita sering berpikir desain itu seperti kontrak: sekali diputuskan, harus dijaga mati-matian. Padahal, dunia bisnis bergerak cepat. Aturan baru muncul, model berubah, skala sistem bertambah, bahkan teknologi pun bergeser.

Keputusan yang dulu tepat bisa jadi tidak relevan hari ini. Maka, desain yang sehat bukan yang “tidak berubah”, tapi yang mudah berubah tanpa menyakitkan.

Contoh sederhana:

Awalnya sistem pembayaran hanya mendukung cash dan transfer bank, jadi cukup enum sederhana:

enum PaymentMethod {
    Cash,
    BankTransfer,
}

Tiga bulan kemudian, muncul kebutuhan baru: QRIS, kartu kredit, e-wallet, bahkan voucher internal.

Kalau arsitektur kita kaku, perubahan kecil seperti ini bisa menyentuh banyak tempat sekaligus — error di mana-mana. Tapi kalau modelnya fleksibel, kita cukup menambah varian baru tanpa mengubah bagian lain:

enum PaymentMethod {
    Cash,
    BankTransfer,
    CreditCard(String),
    EWallet(String),
    Voucher(String),
}

Desain yang bisa berevolusi seperti ini menunjukkan bahwa arsitektur kita adaptif terhadap perubahan pengetahuan.

Desain Itu Proses Pembelajaran

Khononov menjelaskan bahwa desain bukan hasil akhir dari perencanaan panjang, melainkan hasil iterasi dari proses belajar.

Setiap diskusi dengan domain expert, setiap bug, dan setiap perilaku pengguna membawa insight baru tentang domain. Dengan setiap wawasan baru itu, kita perlu memperbarui model, dan kadang mengubah keputusan desain sebelumnya.

“Design is learning, and learning means change.” — Vlad Khononov, 2022

Desain DDD bukan soal menemukan struktur paling indah, tapi soal menemukan struktur yang paling menggambarkan kenyataan saat ini.

Perbedaan Antara Desain yang Kaku dan Desain yang Berevolusi

Aspek Desain Kaku

• Fokus: Kepastian

• Tujuan: Menghindari perubahan

• Strategi: Rencana besar di awal

• Efek samping: Cepat usang

• Pola pikir: “Sudah benar dari awal”

Aspek Desain Berevolusi

• Fokus: Adaptasi

• Tujuan: Menyambut perubahan

• Strategi: Iterasi kecil dan terus-menerus

• Efek samping: Selalu relevan

• Pola pikir: “Kita belajar setiap hari”

Desain kaku lahir dari ketakutan akan salah. Desain yang berevolusi lahir dari rasa ingin tahu dan keberanian untuk mengoreksi diri.

Teknik: Menunda Keputusan Secara Sengaja

Salah satu prinsip desain penting yang diperkenalkan dalam buku ini adalah delaying decisions — menunda keputusan desain sampai kita punya cukup informasi.

Istilah ini sering disebut Last Responsible Moment:

“Ambil keputusan selambat mungkin, tapi tidak sampai terlambat.”

Artinya, jangan buat keputusan desain besar saat masih banyak ketidakpastian. Ambil keputusan yang paling ringan dulu, yang bisa dengan mudah diubah nanti.

Contoh: Daripada langsung memilih pattern besar seperti CQRS + Event Sourcing, mulailah dengan Layered Architecture. Begitu sistem makin kompleks dan kebutuhan audit muncul, kamu bisa evolusikan jadi CQRS.

Atau, daripada menentukan teknologi database di awal, abstraksikan akses datanya lewat Repository Interface. Kalau nanti migrasi dari SQLite ke PostgreSQL, domain model tetap aman.

trait OrderRepository {
    fn save(&self, order: &Order);
    fn find_by_id(&self, id: u64) -> Option<Order>;
}

Keputusan kecil ini menjaga fleksibilitas tanpa mengorbankan arah.

Prinsip: Keputusan Harus Proporsional dengan Pengetahuan

Khononov menyebut bahwa setiap keputusan desain adalah pertukaran antara pengetahuan dan risiko.

• Semakin sedikit pengetahuan yang kita punya, semakin besar risiko salah mengambil keputusan.

• Maka, keputusan harus sepadan dengan tingkat pemahaman kita saat itu.

Jangan terlalu dini membuat keputusan besar atas asumsi mentah. Sebaliknya, jangan juga terlalu lama menunda hingga tim kehilangan arah.

Prinsip ini mendorong pola pikir evolutionary architecture, arsitektur yang tidak selesai di atas kertas, melainkan terus dibentuk dari pengalaman nyata.

Tanda-tanda Kamu Butuh Mengubah Desain

1. Banyak “if” di mana-mana. Itu tanda model sudah tidak mencerminkan domain lagi.

2. Aturan bisnis sulit dijelaskan lewat kode. Mungkin modelmu sudah terlalu teknis.

3. Istilah di kode dan di meeting mulai berbeda. Bahasa umum (ubiquitous language) sudah melenceng.

4. Perubahan kecil memengaruhi banyak bagian. Tanda struktur sistem sudah terlalu rapuh.

5. Tim mulai takut refactor. Ini gejala klasik desain yang membatu.

Kalau ini mulai terasa, jangan panik. Itu bukan kegagalan, itu sinyal bahwa kamu sudah belajar sesuatu yang baru, dan saatnya model ikut berubah.

Pendekatan: Continuous Refinement

Evolusi desain tidak butuh revolusi besar setiap enam bulan. Cukup lakukan refinement kecil secara terus-menerus.

Langkah sederhananya:

1. Identifikasi pain point. Misalnya entitas tertentu jadi terlalu besar.

2. Diskusikan dengan domain expert. Apakah ada istilah atau proses baru?

3. Perbaiki model. Pecah aggregate, ubah value object, atau tambahkan event.

4. Uji asumsi. Pastikan perubahan benar-benar memudahkan pemahaman bisnis.

5. Rilis kecil. Jangan tunda sampai “semua siap”.

Refinement yang berkelanjutan jauh lebih sehat daripada refactor masif yang menakutkan.

Mengelola Tekanan dan Trade-off

Kadang manajemen ingin keputusan cepat: “Pilih framework sekarang!” Atau: “Kita harus finalkan model minggu ini!”

Dalam konteks DDD, tugas engineer bukan hanya membuat kode, tapi juga melindungi proses belajar. Artinya, jangan biarkan tekanan waktu membunuh kesempatan untuk memahami domain dengan benar.

Kita boleh mengambil keputusan pragmatis sementara — asal sadar bahwa itu keputusan sementara, dan siap diperbaiki nanti.

“Every temporary decision is a debt — pay it back when knowledge grows.” — Vlad Khononov, 2022

Kode Sebagai Dokumentasi Evolusi

Model domain yang baik seharusnya menjadi dokumentasi hidup tentang cara bisnis bekerja saat ini. Jangan takut kalau modelmu berbeda dari enam bulan lalu — itu tanda kamu belajar.

Gunakan git commit, test case, dan domain event sebagai jejak sejarah evolusi keputusan desain.

Contoh:

// Sebelum
enum DeliveryStatus {
    Pending,
    Delivered,
}

// Setelah memahami proses retur
enum DeliveryStatus {
    Pending,
    Delivered,
    Returned(String), // alasan pengembalian
}

Setiap perubahan semacam ini adalah bukti bahwa sistemmu menyesuaikan diri dengan realitas bisnis, bukan sebaliknya.

Ringkasan mengenai Desain yang Tumbuh Bersama Pengetahuan

DDD bukan hanya tentang membuat model domain, tapi tentang membangun sistem yang terus belajar.

Desain yang baik tidak kaku. Ia tumbuh bersama tim, bersama bisnis, dan bersama waktu.

Prinsip utamanya sederhana:

• Jangan kunci keputusan sebelum waktunya.

• Jangan takut mengubah arah saat pengetahuan bertambah.

• Dan yang paling penting: pastikan perubahan desain selalu mengikuti makna bisnis, bukan sekadar selera teknis.

“The best design is the one that fits the current understanding of the domain — and is ready to change when that understanding grows.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Referensi

Khononov, V. (2022). Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media.