Struktur Proyek ASP.NET Core yang Baik dan Mudah Dipelihara

 

Di artikel sebelumnya, kita berhasil membuat Web API pertama kita. Visual Studio secara otomatis membuatkan struktur proyek untuk kita: ada folder Controllers, Program.cs, dan beberapa file konfigurasi. Untuk proyek sederhana, ini sudah cukup.

Tapi, apa yang terjadi ketika aplikasi kita tumbuh semakin besar?

Jika kita meletakkan semua logika—validasi, interaksi database, proses bisnis—langsung di dalam Controller, maka Controller kita akan menjadi sangat "gemuk" (fat controller). Kode menjadi sulit dibaca, sulit diuji, dan sulit dipelihara. Saat satu bagian diubah, bagian lain yang tidak berhubungan bisa ikut rusak.

Untuk menghindari kekacauan ini, kita perlu memikirkan arsitektur. Hari ini, kita akan membahas salah satu pendekatan paling populer dan teruji untuk menstrukturkan proyek ASP.NET Core: Arsitektur Berlapis (Layered Architecture).

 

Mengapa Struktur Default Tidak Cukup?

 

Struktur default ASP.NET Core Web API sangat bagus untuk memulai. Namun, ia tidak secara eksplisit memisahkan "concern" atau tanggung jawab. Controller akhirnya melakukan terlalu banyak hal:

1. Menerima HTTP request.

2. Memvalidasi input.

3. Menjalankan logika bisnis.

4. Berinteraksi langsung dengan database.

5. Mengembalikan HTTP response.

Ini melanggar Prinsip Tanggung Jawab Tunggal (Single Responsibility Principle). Idealnya, sebuah Controller hanya perlu melakukan tugas nomor 1 dan 5. Sisanya harus didelegasikan ke lapisan lain.

 

Memperkenalkan Arsitektur Berlapis

 

Gagasan utamanya adalah memecah proyek kita menjadi beberapa proyek terpisah (dalam satu solution) yang masing-masing memiliki tanggung jawab yang jelas. Struktur yang umum digunakan adalah:

1. Core / Domain: Jantung dari aplikasi kita.

2. Infrastructure: "Bagaimana" cara kita melakukan sesuatu (misal: database).

3. Application: "Apa" yang dilakukan oleh aplikasi kita (logika bisnis).

4. API / Presentation: Pintu masuk ke aplikasi kita.

Mari kita bedah satu per satu.

 

1. Proyek Core (atau Domain)

 

Ini adalah lapisan terdalam dan paling independen. Ia tidak boleh bergantung pada lapisan lain.

• Isinya:

  • Entities: Representasi dari objek-objek utama bisnis Anda (misal: class User, Product, Order).

  • Interfaces (Abstraksi): Kontrak atau "aturan main" untuk lapisan lain. Contohnya, IUserRepository yang mendefinisikan "apa" yang bisa dilakukan terkait data user (seperti GetUserById), tapi tidak peduli "bagaimana" caranya.

• Aturan: Proyek ini adalah "pusat alam semesta". Ia tidak boleh mereferensikan proyek lain.

 

2. Proyek Infrastructure

 

Lapisan ini berisi implementasi konkret dari interface yang ada di Core. Ini adalah lapisan teknis.

• Isinya:

  • Implementasi Repository: UserRepository yang mengimplementasikan IUserRepository. Di sinilah kode Entity Framework Core (interaksi database) berada.

  • Integrasi Pihak Ketiga: Kode untuk mengirim email, melakukan pembayaran, atau terhubung ke layanan eksternal lainnya.

• Aturan: Proyek ini mereferensikan proyek Core.

 

3. Proyek Application

 

Ini adalah "otak" dari aplikasi kita, tempat semua logika bisnis dan alur kerja berada.

• Isinya:

  • Services: UserService yang menggunakan IUserRepository untuk menjalankan logika bisnis (misal: mendaftarkan pengguna baru, memvalidasi data, dll).

  • DTOs (Data Transfer Objects): Objek yang digunakan untuk mentransfer data antara lapisan.

• Aturan: Proyek ini mereferensikan proyek Core. Ia tidak tahu-menahu tentang Infrastructure atau API, ia hanya berbicara melalui interface.

 

4. Proyek API (atau Presentation)

 

Ini adalah proyek ASP.NET Core Web API kita yang asli. Lapisan terluar yang berfungsi sebagai pintu masuk.

• Isinya:

  • Controllers: Controller kita sekarang menjadi sangat "kurus". Tugasnya hanya menerima request, memanggil service yang sesuai di lapisan Application, dan mengembalikan hasilnya sebagai respons.

• Aturan: Proyek ini mereferensikan proyek Application.

 

Kesimpulan: Investasi Jangka Panjang

 

Menerapkan arsitektur seperti ini pada awalnya mungkin terasa seperti pekerjaan tambahan. Anda harus membuat beberapa proyek, mengatur dependensi, dan menulis interface.

Namun, percayalah, ini adalah investasi yang akan terbayar lunas. Keuntungannya sangat besar:

• Mudah Dipelihara: Setiap lapisan punya tanggung jawab jelas.

• Mudah Diuji: Anda bisa menguji logika bisnis di lapisan Application secara terpisah tanpa perlu menjalankan web server atau database.

• Fleksibel: Ingin mengganti database dari SQL Server ke PostgreSQL? Anda hanya perlu mengubah implementasi di lapisan Infrastructure, tanpa menyentuh Core atau Application.

Memulai dengan struktur yang baik adalah kunci untuk membangun aplikasi yang tidak hanya berfungsi hari ini, tetapi juga bisa tumbuh dan beradaptasi di masa depan.