Membongkar Paradigma Clean Architecture: Strategi Isolasi Bisnis untuk Aplikasi yang Kebal Perubahan

Bagi seorang software engineer, momen ketika sebuah aplikasi tumbuh membesar sering kali menjadi awal dari sebuah mimpi buruk. Fitur baru yang awalnya bisa diselesaikan dalam hitungan jam, tiba-tiba membutuhkan waktu berhari-hari. Mengubah skema database terasa seperti menjinakkan bom waktu yang bisa merusak modul lain, dan migrasi framework terasa seperti mustahil dilakukan tanpa menulis ulang aplikasi dari nol.

Mengapa ini terjadi? Masalahnya jarang terletak pada kualitas kode individual Anda, melainkan pada bagaimana Anda menyusun komponen-komponen tersebut. Di sinilah Clean Architecture hadir bukan sekadar sebagai tren, melainkan sebagai metodologi krusial untuk menyelamatkan proyek Anda dari pembusukan kode (code rot).

Artikel ini tidak akan mengulang tutorial standar tentang "cara membagi folder". Kita akan membedah Clean Architecture dari sudut pandang yang lebih mendalam: Isolasi Logika Bisnis dan bagaimana arsitektur ini memastikan aplikasi Anda tetap adaptif terhadap perubahan teknologi di masa depan.

---

Inti Masalah: Mengapa Arsitektur Tradisional Gagal?

Dalam arsitektur 3-Tier konvensional (Presentation $\rightarrow$ Business $\rightarrow$ Data), terdapat ketergantungan linier yang berbahaya. Logika bisnis sering kali sangat terikat dengan cara data disimpan. Ketika Anda mengubah struktur tabel di database, efek dominonya akan merambat naik hingga ke lapisan tampilan.

Clean Architecture, yang dipopulerkan oleh Robert C. Martin (Uncle Bob), membalikkan arah ketergantungan ini menggunakan prinsip Dependency Inversion. Aturan utamanya sangat mutlak: Lapisan dalam tidak boleh tahu apa-apa tentang lapisan luar.

Logika bisnis inti Anda harus berada di pusat (lapisan paling dalam), sepenuhnya buta terhadap apakah Anda menggunakan PostgreSQL atau MongoDB, dan tidak peduli apakah interface aplikasi Anda berupa REST API, GraphQL, atau bahkan CLI (Command Line Interface).

---

Anatomi Lapisan: Membedah 4 Lapisan Utama

Mari kita bedah Clean Architecture dari lapisan paling dalam hingga lapisan paling luar secara konseptual.

1. Entities (Enterprise Business Rules)

Entity adalah jantung dari aplikasi Anda. Lapisan ini merangkum aturan bisnis yang paling umum dan mendasar. Aturan di sini adalah aturan yang tidak akan berubah bahkan jika aplikasi Anda berganti model bisnis digital ke konvensional.

• Karakteristik: Berupa objek dengan metode, atau sekadar sekumpulan struktur data.
• Kekebalan: Lapisan ini sama sekali tidak boleh mengimport library eksternal (termasuk framework ORM atau validator pihak ketiga).

2. Use Cases (Application Business Rules)

Use Case (sering disebut Interactors) mengontrol aliran data dari dan ke entities. Lapisan ini mewujudkan fungsionalitas spesifik dari aplikasi Anda.

• Contoh: TransferDanaUseCase, RegisterUserUseCase.
• Karakteristik: Lapisan ini mengisolasi bagaimana sistem beroperasi, namun tetap tidak tahu bagaimana data diambil dari database atau bagaimana hasil akhirnya ditampilkan ke layar.

3. Interface Adapters (Presenters, Controllers, Gateways)

Lapisan ini bertindak sebagai penerjemah data. Ia mengubah data dari format yang paling nyaman untuk use case dan entities, ke format yang paling nyaman untuk eksternal (seperti database atau web).

• Controllers: Menerima input dari luar (misal: HTTP Request), memvalidasi formatnya, dan meneruskannya ke Use Case.
• Repositories/Gateways: Implementasi antarmuka (interface) untuk akses data. Di sinilah query ditulis.

4. Frameworks & Drivers (Web, UI, External Interfaces)

Ini adalah lapisan paling luar yang berisi alat-alat (tools) seperti framework web (Express, NestJS, Spring Boot), driver database, perangkat keras, atau SDK pihak ketiga. Lapisan ini adalah bagian yang paling sering berubah, dan Clean Architecture sengaja menempatkannya di luar agar mudah diganti.

---

Implementasi Praktis: Membangun dengan TypeScript

Untuk memahami bagaimana "Isolasi" ini bekerja, mari kita implementasikan skenario sederhana: Membuat User Baru. Perhatikan bagaimana lapisan dalam sama sekali tidak bergantung pada framework.

Lapisan 1: Entity

// domain/entities/User.ts
export class User {
  constructor(
    public readonly id: string,
    public readonly name: string,
    public readonly email: string
  ) {
    if (!email.includes("@")) {
      throw new Error("Format email tidak valid");
    }
  }
}

Lapisan 2: Use Case (Menggunakan Inversion of Control)

Perhatikan bahwa Use Case membutuhkan database, tetapi kita tidak meng-import database di sini. Kita menggunakan Interface (kontrak).

// domain/repositories/UserRepository.interface.ts
import { User } from "../entities/User";

export interface IUserRepository {
  findByEmail(email: string): Promise<User | null>;
  save(user: User): Promise<void>;
}

// use-cases/CreateUser.ts
import { User } from "../domain/entities/User";
import { IUserRepository } from "../domain/repositories/UserRepository.interface";

interface CreateUserInput {
  name: string;
  email: string;
}

export class CreateUserUseCase {
  // Dependency Injection melalui constructor
  constructor(private userRepository: IUserRepository) {}

  async execute(input: CreateUserInput): Promise<User> {
    const existingUser = await this.userRepository.findByEmail(input.email);
    if (existingUser) {
      throw new Error("Email sudah terdaftar");
    }

    const newUser = new User(crypto.randomUUID(), input.name, input.email);
    await this.userRepository.save(newUser);
    
    return newUser;
  }
}

Lapisan 3 & 4: Adapter dan Framework (Sisi Luar)

Di sinilah kita mengimplementasikan kontrak tersebut menggunakan perkakas nyata (misal: Prisma ORM dan Express).

// infrastructure/repositories/PrismaUserRepository.ts
import { IUserRepository } from "../../domain/repositories/UserRepository.interface";
import { User } from "../../domain/entities/User";
import { PrismaClient } from "@prisma/client";

export class PrismaUserRepository implements IUserRepository {
  private prisma = new PrismaClient();

  async findByEmail(email: string): Promise<User | null> {
    const rawData = await this.prisma.userModel.findUnique({ where: { email } });
    if (!rawData) return null;
    return new User(rawData.id, rawData.name, rawData.email);
  }

  async save(user: User): Promise<void> {
    await this.prisma.userModel.create({
      data: { id: user.id, name: user.name, email: user.email }
    });
  }
}

Ketika Express membuat route, kita merangkai semuanya:

// infrastructure/web/ExpressController.ts
import express from "express";
import { CreateUserUseCase } from "../../use-cases/CreateUser";
import { PrismaUserRepository } from "../repositories/PrismaUserRepository";

const router = express.Router();
const userRepository = new PrismaUserRepository();
const createUserUseCase = new CreateUserUseCase(userRepository);

router.post("/users", async (req, res) => {
  try {
    const { name, email } = req.body;
    const result = await createUserUseCase.execute({ name, email });
    res.status(201).json(result);
  } catch (error: any) {
    res.status(400).json({ error: error.message });
  }
});

---

Keuntungan Finansial dan Teknis untuk Jangka Panjang

Menerapkan Clean Architecture membutuhkan usaha ekstra di awal (boilerplate code yang banyak). Namun, investasi ini terbayar lunas ketika aplikasi Anda mulai menua:

• Uji Coba Tanpa Hambatan (High Testability): Anda dapat menguji seluruh logika bisnis (CreateUserUseCase) tanpa perlu menyalakan database atau server web. Cukup buat Mock Repository palsu di memori. Pengujian menjadi instan dan stabil.
• Bebas Vendor Lock-in: Jika besok biaya penyewaan database SQL Anda membengkak dan manajemen memutuskan migrasi ke NoSQL, Anda hanya perlu membuat class baru (misal: MongoUserRepository) yang mengimplementasikan IUserRepository. Lapisan bisnis Anda? Tidak disentuh sedikit pun.
• Parallel Development: Tim frontend dan backend dapat bekerja lebih sinkron karena kontrak antarmuka (interface) sudah didefinisikan dengan jelas di awal di lapisan domain.

---

Kapan Anda Harus Menghindari Clean Architecture?

Arsitektur ini bukan peluru perak (silver bullet). Ada kalanya Clean Architecture justru menjadi bumerang:

Prinsip Over-Engineering: Jika Anda hanya membangun aplikasi berskala kecil, aplikasi CRUD sederhana, atau produk MVP (Minimum Viable Product) yang umurnya diproyeksikan hanya beberapa bulan untuk validasi pasar, hindari Clean Architecture. Kebanyakan lapisan abstraksi justru akan memperlambat kecepatan rilis produk Anda.

Pilihlah Clean Architecture ketika kompleksitas domain bisnis Anda tinggi, dikerjakan oleh tim yang besar, dan diproyeksikan untuk hidup serta berkembang dalam hitungan tahun.

---

Kesimpulan: Mindset Lebih Penting daripada Struktur Folder

Banyak developer terjebak pada aturan kaku mengenai nama-nama folder saat menerapkan Clean Architecture. Ingatlah bahwa Clean Architecture adalah tentang tata letak dependensi, bukan tentang struktur direktori.

Kunci utamanya adalah disiplin untuk menjaga agar kode yang berisi kebijakan bisnis tidak tercemar oleh detail teknis dari framework eksternal. Dengan memegang teguh prinsip ini, aplikasi yang Anda bangun hari ini akan siap menghadapi ketidakpastian teknologi di masa mendatang.