Lapisan Service: Otak Aplikasi Anda untuk Logika Bisnis yang Bersih dan Teruji

1. Pendahuluan

Pernahkah Anda merasa kode aplikasi web Anda semakin rumit seiring bertambahnya fitur? Logika bisnis tersebar di mana-mana—di controller, di model, bahkan di utility functions yang tidak jelas. Akibatnya, sulit untuk menguji satu bagian kode tanpa memicu bagian lain, perubahan kecil bisa menyebabkan efek samping tak terduga, dan developer baru kesulitan memahami alur aplikasi. Jika ini terdengar familiar, Anda tidak sendirian. Ini adalah masalah umum dalam pengembangan perangkat lunak yang sering disebut “God Object” atau “Spaghetti Code”.

Di sinilah Service Layer hadir sebagai penyelamat. Lapisan service adalah salah satu pola desain arsitektur paling fundamental yang membantu kita mengorganisir logika bisnis aplikasi secara bersih, terpisah, dan teruji. Dalam artikel ini, kita akan menyelami apa itu Service Layer, mengapa ia begitu penting, bagaimana cara menerapkannya dengan benar, serta tantangan yang mungkin Anda hadapi. Mari kita bangun aplikasi yang lebih cerdas dan tangguh!

2. Apa itu Service Layer?

Secara sederhana, Service Layer adalah lapisan dalam arsitektur aplikasi Anda yang bertanggung jawab untuk mengimplementasikan logika bisnis inti. Ia bertindak sebagai orkestrator yang menerima permintaan, melakukan serangkaian operasi bisnis, dan mengembalikan hasilnya.

📌 Posisi dalam Arsitektur: Bayangkan aplikasi Anda seperti sebuah restoran.

• Customer (Pengguna Akhir): Mengirim permintaan (misal: “Saya mau pesan Nasi Goreng”).
• Pelayan (Controller/API Handler): Menerima pesanan dari customer. Pelayan tidak memasak sendiri, bukan? Dia hanya meneruskan pesanan.
• Koki (Service Layer): Inilah otak dapur. Koki tahu resep Nasi Goreng (logika bisnis), mengambil bahan (data dari database via Repository), memasak (memproses logika), dan menyajikannya (mengembalikan hasil ke pelayan).
• Gudang Bahan Makanan (Repository/Data Access Layer): Tempat koki mengambil dan menyimpan bahan.

Dalam konteks teknis:

• Presentation Layer (Controller/Handler/Frontend UI): Menerima input dari pengguna (HTTP request, UI event) dan memanggil metode di Service Layer.
• Service Layer: Berisi logika bisnis utama. Ia mengkoordinasikan operasi, memvalidasi data, memanggil Repository untuk interaksi database, atau berinteraksi dengan layanan eksternal.
• Data Access Layer (Repository): Bertanggung jawab untuk operasi CRUD (Create, Read, Update, Delete) dengan database atau sumber data lainnya.

🎯 Tanggung Jawab Utama Service Layer:

1. Orkestrasi Logika Bisnis: Menggabungkan beberapa operasi tingkat rendah (misalnya, membuat pengguna, mengirim email notifikasi, mencatat log aktivitas) menjadi satu alur bisnis yang kohesif.
2. Validasi Bisnis: Memastikan bahwa data dan operasi mematuhi aturan bisnis (berbeda dengan validasi input dasar di Presentation Layer).
3. Manajemen Transaksi: Mengelola transaksi database untuk memastikan konsistensi data di seluruh operasi.
4. Akses ke Sumber Data/Layanan Eksternal: Menggunakan Repository atau klien API eksternal untuk mendapatkan atau menyimpan data yang diperlukan.

3. Anatomi Sebuah Service

Sebuah service yang baik biasanya:

• Fokus pada Satu Domain atau Use Case: Misalnya, UserService untuk semua operasi terkait pengguna, OrderService untuk pesanan, PaymentService untuk pembayaran. Ini mengikuti Prinsip Tanggung Jawab Tunggal (Single Responsibility Principle - SRP).
• Berbasis Kontrak (Interface): Seringkali didefinisikan melalui interface atau class abstrak, memungkinkan implementasi yang berbeda dan mempermudah testing.
• Menggunakan Dependencies: Services akan ‘mengonsumsi’ dependencies seperti repository, layanan notifikasi, atau layanan eksternal lainnya melalui Dependency Injection.

Mari kita lihat contoh kode sederhana di TypeScript/Node.js:

// ----------------------------------------------------
// 1. DTO (Data Transfer Object) untuk input dan output
// ----------------------------------------------------
interface CreateUserRequest {
  name: string;
  email: string;
  password?: string; // Opsional jika auto-generate
}

interface UserResponse {
  id: string;
  name: string;
  email: string;
  createdAt: Date;
}

// ----------------------------------------------------
// 2. Repository (Lapisan Data Access)
// ----------------------------------------------------
interface UserRepository {
  findById(id: string): Promise<UserResponse | null>;
  findByEmail(email: string): Promise<UserResponse | null>;
  create(user: CreateUserRequest): Promise<UserResponse>;
  update(id: string, data: Partial<CreateUserRequest>): Promise<UserResponse | null>;
  delete(id: string): Promise<boolean>;
}

// Implementasi dummy untuk contoh
class InMemoryUserRepository implements UserRepository {
  private users: UserResponse[] = [];
  private nextId = 1;

  async findById(id: string): Promise<UserResponse | null> {
    return this.users.find(u => u.id === id) || null;
  }

  async findByEmail(email: string): Promise<UserResponse | null> {
    return this.users.find(u => u.email === email) || null;
  }

  async create(user: CreateUserRequest): Promise<UserResponse> {
    const newUser: UserResponse = {
      id: (this.nextId++).toString(),
      name: user.name,
      email: user.email,
      createdAt: new Date(),
    };
    this.users.push(newUser);
    return newUser;
  }

  async update(id: string, data: Partial<CreateUserRequest>): Promise<UserResponse | null> {
    const index = this.users.findIndex(u => u.id === id);