Featured_Image_part-1-repository-pattern-solusi-untuk-duplicate-code-decoupling-dan-clean-code

Part 1: Repository Pattern – Solusi untuk Duplicate Code, Decoupling, dan Clean Code

Dalam pengembangan aplikasi, terutama yang melibatkan akses ke database, sering kali developer menulis ulang query yang mirip di berbagai tempat. Misalnya, query untuk mendapatkan user berdasarkan ID, mencari data dengan filter tertentu, atau menyimpan entitas baru. Hal ini sering menimbulkan duplicate code, tanpa disadari oleh developer.

Bayangkan kamu sedang mengembangkan sebuah aplikasi yang butuh sering berkomunikasi dengan database. Misalnya, untuk mencari data user, menyimpan data transaksi, atau mengupdate status pesanan.

Awalnya, semua terasa sederhana: langsung saja tulis query di dalam service atau bahkan controller. Cepat, praktis, jalan! 🚀

Tapi lama-kelamaan, ada masalah yang muncul:

  • Kode yang sama muncul di banyak tempat.
    Kamu mungkin punya query WHERE active = 1 yang dipakai di tiga service berbeda. Ketika ada perubahan aturan (misalnya aktif sekarang artinya status = 'A'), semua bagian itu harus diperbaiki.
  • Service terlalu bergantung pada database.
    Service tahu persis kalau datanya ada di MySQL, query-nya harus begini, tabelnya harus begitu. Kalau nanti database diganti ke PostgreSQL atau bahkan pindah ke API eksternal, pekerjaan refaktor jadi luar biasa besar.
  • Kode jadi berantakan.
    Service yang seharusnya fokus pada logika bisnis malah penuh dengan detail teknis query.

Di sinilah Repository Pattern muncul sebagai penyelamat.

Apa Itu Repository Pattern?
Repository Pattern adalah sebuah lapisan perantara antara kode logika bisnis (service) dan sumber data (database, API, cache, dsb).

Kamu bisa menganggap repository seperti “perpustakaan data pribadi”. Service tidak perlu tahu bagaimana data diambil. Cukup bilang:

  • “Tolong ambilkan semua user aktif”
  • “Tolong carikan user dengan email tertentu”

Detail teknis pencarian itu semua diurus repository.

Kenapa Repository Pattern Penting?
1. Menghindari Duplicate Code

Daripada menulis query yang sama berkali-kali di berbagai tempat, kamu cukup menulisnya sekali di repository.

2. Membuat Kode Terpisah dengan Rapi (Decoupling)

Service tidak lagi terikat pada satu jenis database. Kalau suatu hari pindah dari MySQL ke MongoDB, kamu hanya perlu mengganti repository, tanpa menyentuh service.

3. Lebih Mudah Dibaca dan Dipelihara (Clean Code)

Service jadi fokus pada logika bisnis: apa yang harus dilakukan dengan data.
Repository fokus pada detail teknis: bagaimana cara mendapatkan data.

Ilustrasi Sederhana
Tanpa Repository

class UserService {
    public function getActiveUsers() {
        return DB::table('users')->where('active', 1)->get();
    }

    public function getUserByEmail($email) {
        return DB::table('users')->where('email', $email)->first();
    }
}

Sekilas terlihat normal. Tapi coba bayangkan kalau besok ada aturan baru, atau query berubah. Semua service yang punya query serupa harus ikut diubah.

Dengan Repository

interface UserRepository {
    public function allActive();
    public function findByEmail(string $email);
}

class EloquentUserRepository implements UserRepository {
    public function allActive() {
        return User::where('active', 1)->get();
    }

    public function findByEmail(string $email) {
        return User::where('email', $email)->first();
    }
}

class UserService {
    protected $users;

    public function __construct(UserRepository $users) {
        $this->users = $users;
    }

    public function listActiveUsers() {
        return $this->users->allActive();
    }

    public function getUserDetail($email) {
        return $this->users->findByEmail($email);
    }
}

Kini, semua query dikumpulkan di repository. Service jadi jauh lebih rapi dan fokus.

epository Pattern bukan sekadar “gaya arsitektur”, tapi sebuah cara berpikir:

  • Hindari pengulangan kode.
  • Jaga agar kode tidak terlalu bergantung pada detail teknis.
  • Buat kode lebih bersih, rapi, dan mudah dipelihara.

Dengan Repository Pattern, aplikasi terasa lebih fleksibel. Service bisa fokus menjalankan logika bisnis, sementara detail teknis query disembunyikan rapi di repository.

Kalau diibaratkan, service adalah koki, repository adalah asisten dapur. Koki tinggal bilang: “Ambilkan bahan ini, ambilkan bumbu itu”. Tidak perlu turun tangan ke pasar sendiri.

Understanding Testing Driven Development (TDD): Challenges, Common Mistakes, and Its Powerful Benefits
The Journey of Machine Learning: From Simple Experiments to Artificial Intelligence