Dalam pengembangan perangkat lunak, praktik membuat objek data khusus untuk mengelola interaksi dengan bagian-bagian tertentu dari database telah lama menjadi pilar arsitektur aplikasi. Framework seperti Django dan berbagai ORM telah menginstitusionalisasi pola ini, menjanjikan abstraksi yang bersih atas lapisan persistensi. Namun, semakin banyak developer yang kini mempertanyakan apakah pendekatan satu-untuk-semua ini justru menciptakan lebih banyak masalah daripada solusi, terutama seiring aplikasi yang berkembang dan semakin kompleks. Diskusi komunitas mengungkapkan bahwa apa yang dulu dianggap sebagai praktik terbaik kini semakin dipandang sebagai sumber kompleksitas dan kekakuan.
Ledakan Kombinatorial Konteks
Poin perselisihan utama berkisar pada tantangan menggunakan objek data yang sama di berbagai bagian aplikasi. Objek User, misalnya, mungkin digunakan untuk autentikasi dan manajemen profil. Data yang diperlukan untuk login—mungkin hanya email dan kata sandi—merupakan bagian kecil dari profil pengguna lengkap. Memaksa fungsi login untuk menerima objek User yang monolitik berarti ia harus membawa seluruh muatan data pengguna, yang sebagian besar tidak relevan dengan tugasnya. Hal ini membuat refactoring menjadi mimpi buruk, karena setiap perubahan pada objek User harus mempertimbangkan semua penggunaannya, bahkan yang sama sekali tidak terkait dengan perubahan tersebut. Alternatifnya—membuat banyak objek yang lebih kecil dan spesifik konteks—dapat menghindari hal ini tetapi menyebabkan proliferasi kelas yang terasa berantakan dan berulang.
Itulah mengapa sangat sulit untuk melakukan refactoring sistem besar yang diprogram dengan gaya ini. Penulis mengamati ledakan kombinatorial fakta!
Sentimen ini menggema realisasi yang lebih luas: mencoba menangkap rangkaian fakta tak terbatas tentang konsep dunia nyata seperti Pengguna dalam satu kelas adalah usaha yang pada dasarnya cacat. Konteks aplikasi yang berbeda membutuhkan pandangan yang berbeda tentang data dasar yang sama, dan satu objek kanonik seringkali tidak dapat melayani semua kebutuhan ini secara efektif tanpa menjadi gemuk dan sulit dirawat.
Kritik Umum terhadap Universal Data Objects:
- Ledakan Kombinatorial: Sebuah objek tunggal tidak dapat secara efisien merepresentasikan semua kemungkinan tampilan dari sebuah entitas di berbagai konteks aplikasi.
- Kesulitan Refactoring: Perubahan pada objek data sentral memerlukan pertimbangan terhadap semua penggunaannya, bahkan yang tidak relevan sekalipun.
- Overhead Pengembangan: Kepatuhan ketat terhadap objek-objek yang spesifik konteks (seperti dalam DDD) dapat memperlambat kecepatan pengembangan karena peningkatan pemetaan dan manajemen file.
- Kekakuan Arsitektur: Pola ini dapat mendorong pola akses data yang berbeda (misalnya, pembacaan konsisten vs. pembacaan yang akhirnya konsisten) ke dalam satu antarmuka yang kikuk.
Pertimbangan dalam Peralatan dan Kecepatan Tim
Perdebatan ini juga meluas ke pertimbangan praktis yang terlibat dalam menaati pola seperti Domain-Driven Design (DDD) secara ketat. Meskipun membuat Data Transfer Object (DTO) terpisah untuk konteks yang berbeda dapat meningkatkan akurasi dan pemisahan kepentingan, hal itu datang dengan biaya yang nyata. Lebih banyak objek berarti lebih banyak kode pemetaan, lebih banyak file, dan lebih banyak nama yang harus dikelola. Dalam bahasa seperti Java, hal ini dapat secara signifikan memperlambat kecepatan pengembangan, menyebabkan frustrasi karena perubahan sederhana menghasilkan kaskade file baru. Beberapa developer melaporkan bahwa setelah periode antusiasme awal, tim sering diam-diam memberontak terhadap keketatan DDD murni, menganggap overhead-nya terlalu besar untuk kecepatan bisnis. Hal ini membuat banyak orang mencari jalan tengah, menerapkan prinsip-prinsip ini secara selektif di mana mereka memberikan nilai paling banyak, seperti di area sensitif keamanan seperti autentikasi, daripada secara universal di seluruh basis kode.
Pola Alternatif dan Pergeseran Filosofis
Menanggapi tantangan ini, developer mengeksplorasi pola arsitektur alternatif. Beberapa menganjurkan pendekatan yang lebih berpusat pada fungsi, di mana kueri spesifik mengembalikan tipe yang sesuai dengan bentuk hasil yang tepat, daripada memaksa hasil ke dalam objek entitas yang telah ditentukan sebelumnya. Alat seperti jOOQ, yang menghasilkan kode type-safe dari skema database, dipuji karena memungkinkan gaya ini tanpa perilaku automagic dari beberapa ORM. Hal ini sejalan dengan pergeseran filosofis yang lebih luas, yang didukung oleh bahasa seperti Clojure, menuju pemodelan data sebagai peta sederhana dan generik serta menulis fungsi yang beroperasi padanya. Para pendukung berpendapat bahwa ketika dikombinasikan dengan skema validasi, pendekatan ini dapat menawarkan jaminan struktural sambil menghindari ledakan kombinatorial hierarki kelas, memberikan fondasi yang lebih fleksibel untuk sistem informasi yang kompleks.
Pendekatan Alternatif yang Disebutkan:
- Objek Spesifik Konteks (DTO): Membuat objek terpisah untuk berbagai kasus penggunaan (misalnya,
LoginPayload,UserProfile). - Query Berfokus pada Fungsi: Membangun query yang mengembalikan hasil dalam bentuk tertentu, daripada memaksanya ke dalam objek entitas. Tools seperti jOOQ memfasilitasi hal ini.
- Pemrograman Berfokus pada Data: Menggunakan struktur data sederhana dan generik (seperti maps) dan memvalidasinya dengan skema (misalnya, Clojure dengan spec/malli).
Kekuatan Konvensi dan Prinsip Kejutan Minimal
Terlepas dari kritik, pola objek data tetap sangat mengakar dengan alasan yang baik: itulah yang diharapkan kebanyakan developer. Pengenalan anggota tim baru menjadi lebih mudah ketika basis kode mengikuti konvensi yang familiar. Prinsip kejutan minimal adalah kekuatan yang kuat dalam pengembangan perangkat lunak, mengurangi beban kognitif dan memperlancar jalan menuju produktivitas. Lebih lanjut, bangkitnya alat pengkodean berbantuan AI, atau vibe coding, memperkuat nilai pola umum, karena model bahasa besar biasanya dilatih pada kode yang menggunakan pendekatan standar ini. Menyimpang dari norma dapat membuat bantuan otomatis kurang efektif dan mempersulit pemeliharaan jangka panjang, menyajikan argumen tandingan yang kuat untuk pergeseran arsitektur secara keseluruhan.
Diskusi seputar objek data masih jauh dari selesai. Ini mewakili ketegangan rekayasa perangkat lunak klasik antara abstraksi bersih dari model universal dan realitas berantakan dari persyaratan yang berkembang. Seiring sistem tumbuh, kenyamanan awal dari objek data satu-untuk-semua dapat memberi jalan kepada kompleksitas yang signifikan. Tren saat ini bukanlah meninggalkan pola tersebut sepenuhnya, tetapi menuju penerapannya yang lebih bernuansa dan sadar konteks, menyadari bahwa solusi paling pragmatis sering terletak pada keseimbangan yang bijaksana antara kemurnian arsitektural dan kebutuhan pengembangan praktis.
Referensi: On having a data object