Belajar Menjaga Kelenturan Kode lewat Clean Architecture

Pernahkah kamu merasa bahwa proyek perangkat lunak yang awalnya berjalan sangat cepat, tiba-tiba melambat secara drastis? Awalnya, setiap ide baru bisa diwujudkan menjadi kode dalam hitungan jam, namun lama-kelamaan, menambah satu fitur kecil saja malah membutuhkan waktu berminggu-minggu. Fenomena ini bukan sekadar masalah teknis biasa, melainkan tanda adanya masalah pada struktur sistem yang kamu bangun.

Dalam buku Clean Architecture karya Robert C. Martin, kamu akan diajak untuk memahami mengapa hal ini bisa terjadi dan bagaimana cara mencegahnya. Buku ini memberikan panduan mendalam tentang cara menyusun batasan kode yang bersih agar sistem tetap lentur, mudah diuji, dan hemat biaya perawatan dalam jangka panjang.

Mengapa Sistem Perangkat Lunak Menjadi Lambat dan Mahal?

Banyak pengembang terjebak dalam ilusi bahwa mereka bisa menulis kode asal-asalan demi mengejar kecepatan rilis. Saat ditekan oleh tenggat waktu yang ketat, tim sering kali tergoda untuk mengambil jalan pintas dalam desain. Akibatnya, kekacauan kecil yang dibiarkan menumpuk akan menjadi beban besar di masa depan. Setiap kali kamu ingin mengubah satu baris kode, ada lima bagian lain yang ikut rusak tanpa terduga.

Masalah ini menciptakan siklus yang sangat mahal. Robert C. Martin menceritakan sebuah contoh perusahaan di mana produktivitas tim justru menurun seiring bertambahnya jumlah staf. Meskipun manajemen terus merekrut programmer baru untuk mengejar pertumbuhan produk, grafik produktivitas mereka justru mendatar. Hal ini terjadi karena sistem sudah menjadi begitu rumit dan saling mengunci, sehingga para pengembang menghabiskan sebagian besar waktu mereka hanya untuk menambal kerusakan, bukan membangun fitur baru.

Pada akhirnya, menambah jumlah programmer tidak akan menyelesaikan masalah jika biaya per baris kode terus naik akibat struktur yang buruk. Keuntungan bisnis justru habis terpakai hanya untuk membiayai perbaikan kesalahan masa lalu. Inilah mengapa menjaga kualitas struktur sejak awal jauh lebih penting daripada sekadar mengejar perilaku sistem saat ini.

Memisahkan Aturan Bisnis dari Detail Teknis

Inti dari arsitektur yang bersih adalah kemampuan untuk memisahkan aturan bisnis inti dari detail teknis. Detail teknis adalah hal-hal seperti basis data, antarmuka pengguna (UI), atau kerangka kerja (framework) pihak ketiga. Jika aturan bisnis kamu bercampur aduk dengan detail teknis ini, sistemmu akan menjadi kaku dan sulit untuk diubah.

Untuk memahami hal ini, bayangkan seorang arsitek yang sedang merancang sebuah rumah tinggal. Arsitek tersebut harus memikirkan alur sirkulasi penghuni dan pembagian ruangan secara keseluruhan. Namun, ia juga harus menentukan letak sakelar listrik, titik lampu, hingga jalur pembuangan pipa air. Semua detail kecil ini dibuat agar rumah nyaman dihuni dan mudah diperbaiki di kemudian hari. Tanpa kejelasan jalur pipa, rumah yang tampak megah dari luar akan menyulitkan penghuninya saat terjadi kerusakan.

Dalam pengembangan perangkat lunak, kamu harus memperlakukan detail teknis seperti basis data atau framework sebagai alat bantu, bukan sebagai pusat dari sistem. Salah satu strategi terbaik adalah menunda keputusan infrastruktur selama mungkin. Dengan membiarkan keputusan detail tetap terbuka, kamu menjaga sistem tetap fleksibel saat arah bisnis atau kebutuhan pasar tiba-tiba berubah di tengah jalan.

Menerapkan Prinsip Desain untuk Menjaga Batasan

Agar batasan antar komponen tetap terjaga, kamu perlu menerapkan prinsip-prinsip desain universal. Robert C. Martin menekankan pentingnya disiplin dalam menyusun komponen agar tidak terjadi ketergantungan yang saling mengunci.

Beberapa prinsip penting yang bisa kamu terapkan antara lain:

• Single Responsibility Principle (SRP): Sebuah modul idealnya hanya memiliki satu alasan untuk berubah. Sebagai contoh, jangan menyatukan fungsi perhitungan gaji, laporan jam kerja, dan penyimpanan database ke dalam satu kelas yang sama. Jika ketiga fungsi tersebut melayani pejabat yang berbeda, perubahan pada satu fungsi bisa merusak fungsi lainnya secara tidak sengaja.
• Open-Closed Principle (OCP): Sistem harus terbuka untuk penambahan fitur baru, tetapi tertutup dari perubahan pada kode yang sudah bekerja dengan baik. Caranya adalah dengan membagi sistem ke dalam komponen bertingkat sehingga kamu bisa menambah kemampuan tanpa harus membongkar kode lama.
• Dependency Inversion Principle (DIP): Prinsip ini memastikan bahwa arah ketergantungan selalu mengarah ke kebijakan bisnis yang stabil. Alih-alih kode bisnis bergantung pada modul teknis, buatlah kode bisnis merujuk pada sebuah abstraksi atau antarmuka (interface). Dengan begitu, kamu bisa mengganti alat teknis tanpa menyentuh logika utama.

Membangun Struktur Berbasis Use Case

Arsitektur yang baik seharusnya memberikan kejelasan tentang apa tujuan dari sistem tersebut. Saat seseorang melihat struktur berkas proyekmu, mereka harus bisa langsung melihat fungsinya, seperti modul pembayaran, pemesanan, atau pengiriman barang. Jangan sampai struktur kode kamu justru hanya memperlihatkan merek framework yang kamu gunakan, seperti Spring atau Rails.

Dalam konsep Clean Architecture, aturan bisnis dan skenario penggunaan (use case) harus diletakkan tepat di pusat arsitektur. Konsep ini digambarkan melalui lingkaran konsentris:

1. Lingkaran terdalam: Berisi entitas bisnis atau aturan dasar yang paling stabil.
2. Lapisan berikutnya: Menampung skenario penggunaan (use case) yang mengatur alur data.
3. Lapisan luar: Berisi alat bantu teknis seperti framework web, antarmuka, dan basis data.

Aturan emas yang harus kamu patuhi adalah aturan ketergantungan: arah ketergantungan kode hanya boleh mengalir ke dalam. Kode di lingkaran dalam tidak boleh mengetahui apa pun tentang lapisan di luarnya. Dengan menjaga batasan ini, kamu melindungi inti bisnis dari perubahan alat bantu teknis yang mungkin terjadi di masa depan.

Kesimpulan dan Langkah Selanjutnya

Membangun arsitektur yang bersih memang membutuhkan disiplin dan mungkin terasa lebih berat di awal proyek. Namun, ini adalah investasi jangka panjang untuk menekan biaya perawatan dan memastikan sistemmu tetap bisa berkembang mengikuti kebutuhan bisnis. Jangan biarkan detail teknis mendikte seluruh struktur program yang kamu miliki.

Jika kamu ingin mempelajari lebih dalam mengenai penerapan prinsip SOLID, cara memutus siklus ketergantungan, hingga strategi mengukur stabilitas desain secara konkret, jangan lewatkan kesempatan untuk membaca ringkasan lengkap buku Clean Architecture di aplikasi BacaApps.

Baca ringkasan lengkapnya di BacaApps: Clean Architecture karya Robert C. Martin