Membongkar Paradigma Anti-Fragile: Mengawinkan Clean Architecture dengan Model-Driven Design untuk Skalabilitas Domain Kompleks

Dalam lanskap pengembangan perangkat lunak modern, perubahan adalah satu-satunya kepastian. Regulasi bisnis berganti, pilihan database berevolusi dari relasional ke NoSQL, dan framework yang hari ini dipuji bisa jadi usang dalam waktu tiga tahun ke depan. Masalah terbesar yang sering dihadapi oleh tim engineering berskala besar bukanlah menulis kode baru, melainkan bagaimana mempertahankan kode lama agar tidak runtuh saat struktur bisnis di sekitarnya berubah.

Sebagian besar developer beralih ke Clean Architecture besutan Robert C. Martin (Uncle Bob) sebagai penyelamat. Namun, menerapkan Clean Architecture secara mentah-mentah sering kali berujung pada tumpukan boilerplate yang kaku jika tidak diimbangi dengan pemahaman domain yang kuat.

Artikel ini tidak akan mengulang penjelasan normatif tentang "apa itu Clean Architecture". Kita akan membedah sudut pandang baru yang lebih radikal: bagaimana mengawinkan Clean Architecture dengan prinsip Model-Driven Design (MDD) dari Domain-Driven Design (DDD) untuk menciptakan sistem yang bukan sekadar kokoh (robust), melainkan anti-fragile—sistem yang justru semakin matang dan adaptif ketika diuji oleh perubahan.

---

Intisari Kebal Perubahan: Membalikkan Arah Dependensi

Arsitektur tradisional berbasis n-tier (Presentation $\rightarrow$ Business $\rightarrow$ Data Access) menempatkan database sebagai fondasi. Akibatnya, setiap kali skema database berubah, efek dominonya akan merembes hingga ke kode bisnis dan antarmuka pengguna.

Clean Architecture membalikkan paradigma ini secara ekstrem melalui Dependency Inversion Principle (DIP). Di sinilah letak keajaiban sirkular yang sebenarnya:

Aturan utamanya sangat ketat: Kode di lapisan dalam tidak boleh mengetahui apa pun tentang kode di lapisan luar. * Entities (Domain): Jantung dari aplikasi. Bagian ini berisi aturan bisnis inti (enterprise business rules) dan objek domain yang mencerminkan realitas bisnis, terisolasi total dari dunia luar.

• Use Cases (Application): Berisi aturan bisnis spesifik aplikasi. Lapisan inilah yang mengorkestrasi aliran data ke dan dari entitas.
• Interface Adapters (Interface): Lapisan konverter yang mengubah data dari format yang paling nyaman untuk use cases ke format yang paling nyaman untuk eksternal (seperti REST API, GraphQL, atau UI).
• Frameworks & Drivers (Infrastructure): Lapisan terluar yang berisi peralatan seperti database, web framework, library enkripsi, dan sejenisnya. Lapisan ini adalah detail, bukan inti dari sistem.

---

Mengapa Clean Architecture Saja Tidak Cukup? Masalah Anemic Domain Model

Banyak tim berhasil mengisolasi kode mereka, namun berakhir dengan apa yang disebut Martin Fowler sebagai Anemic Domain Model. Lapisan entitas mereka hanya berisi objek-objek "kebiri" yang penuh dengan getter dan setter tanpa logika bisnis (hanya berupa struktur data). Logika bisnis justru bocor dan menumpuk di lapisan Use Cases.

Ketika Use Cases memegang kendali penuh atas validasi dan manipulasi status entitas, aplikasi menjadi sulit diskalakan secara konseptual. Jika ada 10 use case yang memanipulasi entitas yang sama, aturan bisnis berpotensi terduplikasi atau bergeser di antara 10 tempat tersebut.

Untuk mengatasinya, kita harus menyuntikkan paradigma Model-Driven Design (MDD) ke dalam rahim Clean Architecture.

---

Integrasi Taktis: Clean Architecture + Model-Driven Design

Dengan mengintegrasikan taktik MDD, kita membagi lapisan terdalam (Entities dan Use Cases) menjadi komponen yang lebih kaya secara semantik:

1. Aggregate Root (Domain Layer): Klaster objek domain yang terikat bersama dan diperlakukan sebagai satu unit tunggal untuk perubahan data. Segala mutasi status harus melalui Aggregate Root untuk memastikan konsistensi (invariants).
2. Value Objects (Domain Layer): Objek tanpa identitas konseptual yang didefinisikan hanya oleh propertinya. Objek ini bersifat immutable (tidak dapat diubah setelah dibuat).
3. Domain Services (Domain Layer): Ketika suatu operasi bisnis tidak secara alami menjadi milik satu Entitas atau Value Object tunggal, operasi tersebut dituangkan dalam Domain Service.
4. Repositories Interface (Domain Layer): Kontrak abstraksi untuk membaca dan menulis Aggregate Root, memisahkan logika bisnis dari mekanisme persistensi data.

Mari kita lihat bagaimana struktur ini diimplementasikan secara konkret menggunakan TypeScript.

Studi Kasus: Sistem Manajemen Langganan (Subscription B2B)

Bayangkan kita sedang membangun sistem manajemen langganan perusahaan yang memiliki aturan bisnis: “Sebuah organisasi tidak dapat menambah pengguna baru jika status langganan mereka tidak aktif atau melebihi kuota paket.”

1. Lapisan Domain (Murni, Tanpa Dependensi Eksternal)

Pertama, kita definisikan SubscriptionPlan sebagai Value Object yang immutable.

// domain/value-objects/SubscriptionPlan.ts
export class SubscriptionPlan {
  constructor(
    public readonly maxUsers: number,
    public readonly isActive: boolean
  ) {
    if (maxUsers <= 0) {
      throw new Error("Kuota pengguna harus lebih besar dari nol.");
    }
  }

  public canAccommodate(currentUsersCount: number): boolean {
    return this.isActive && currentUsersCount < this.maxUsers;
  }
}

Selanjutnya, kita rancang Organization sebagai Aggregate Root. Perhatikan bahwa validasi bisnis berada di dalam entitas ini, bukan di Use Case atau Controller.

// domain/entities/Organization.ts
import { SubscriptionPlan } from '../value-objects/SubscriptionPlan';

export class Organization {
  private constructor(
    public readonly id: string,
    private name: string,
    private plan: SubscriptionPlan,
    private memberIds: Set<string>
  ) {}

  // Factory method untuk menjamin pembuatan objek yang valid
  public static create(id: string, name: string, plan: SubscriptionPlan): Organization {
    return new Organization(id, name, plan, new Set<string>());
  }

  // Aturan Bisnis Inti (Invariants)
  public inviteMember(userId: string): void {
    if (!this.plan.canAccommodate(this.memberIds.size)) {
      throw new Error("Gagal mengundang anggota: Paket tidak aktif atau kuota penuh.");
    }
    this.memberIds.add(userId);
  }

  public getMembersCount(): number {
    return this.memberIds.size;
  }

  public getRawMemberIds(): string[] {
    return Array.from(this.memberIds);
  }
}

Kita juga meletakkan Repository Interface di lapisan ini sebagai kontrak.

// domain/repositories/OrganizationRepository.interface.ts
import { Organization } from '../entities/Organization';

export interface IOrganizationRepository {
  findById(id: string): Promise<Organization | null>;
  save(organization: Organization): Promise<void>;
}

2. Lapisan Use Case (Application Layer)

Lapisan ini murni bertindak sebagai orkestrator. Ia mengambil data dari repositori abstrak, memicu fungsi pada domain entitas, dan menyimpan kembali hasilnya.

// application/use-cases/InviteMember.usecase.ts
import { IOrganizationRepository } from '../../domain/repositories/OrganizationRepository.interface';

interface InviteMemberInput {
  organizationId: string;
  userId: string;
}

export class InviteMemberUseCase {
  constructor(private orgRepository: IOrganizationRepository) {}

  public async execute(input: InviteMemberInput): Promise<void> {
    const organization = await this.orgRepository.findById(input.organizationId);
    
    if (!organization) {
      throw new Error("Organisasi tidak ditemukan.");
    }

    // Delegasi logika bisnis sepenuhnya ke domain entity
    organization.inviteMember(input.userId);

    // Persistensi perubahan
    await this.orgRepository.save(organization);
  }
}

---

Keuntungan Strategis Mengawinkan Dua Paradigma

Pendekatan hibrida antara Clean Architecture dan Model-Driven Design ini memberikan sejumlah keuntungan yang signifikan bagi tim developer:

Dimensi	Pendekatan Konvensional (Framework-First)	Pendekatan Clean + Model-Driven
Kemudahan Testing	Sulit, membutuhkan mocking server database, HTTP context, atau ORM yang rumit.	Sangat mudah, pengujian logika bisnis inti ($Entities$) adalah 100% pure unit test tanpa library eksternal.
Ketergantungan Vendor	Terkunci pada satu teknologi (misal: NestJS, TypeORM, Prisma, MongoDB).	Teknologi luar hanyalah detail instalasi. Mengganti PostgreSQL ke DynamoDB tidak mengubah satu baris pun kode bisnis.
Skalabilitas Konseptual	Kode bisnis tersebar di controller, middleware, dan skema DB (menimbulkan friksi).	Aturan bisnis terkonsentrasi rapi di dalam Aggregate Roots dan Value Objects.

---

Menjaga Perbatasan: Strategi Mencegah Kebocoran Lapisan

Agar arsitektur ini tidak tererosi seiring berjalannya waktu akibat desakan deadline proyek, tim engineering wajib menegakkan aturan isolasi yang ketat:

1. Gunakan Data Transfer Objects (DTO): Jangan pernah melemparkan objek Entitas langsung ke lapisan Controller atau keluar sebagai respons HTTP JSON. Jika Entitas bocor ke luar, perubahan internal pada struktur entitas akan mematahkan kontrak API publik Anda. Gunakan konverter/mapper untuk mengubah Entitas menjadi DTO di lapisan Interface Adapters.
2. Anti-Corruption Layer (ACL): Saat sistem Anda harus berkomunikasi dengan sistem warisan (legacy) atau pihak ketiga yang berantakan, buatlah lapisan penerjemah (ACL) di lingkaran terluar (Infrastructure). Jangan biarkan model data pihak ketiga mendikte atau mengotori bahasa domain internal Anda (Ubiquitous Language).

---

Kesimpulan

Clean Architecture bukanlah sebuah aturan kaku tentang bagaimana Anda menyusun folder dalam proyek Anda. Clean Architecture adalah sebuah manifesto mental tentang pemisahan kepedulian (Separation of Concerns) dan proteksi aset terpenting Anda: logika bisnis.

Dengan mengintegrasikannya bersama taktik Model-Driven Design, Anda tidak hanya memisahkan kode dari framework, tetapi juga memberikan struktur berorientasi objek yang kaya di dalam domain Anda. Hasilnya adalah sistem yang anti-fragile—sebuah arsitektur yang siap, lentur, dan justru berkembang di tengah badai perubahan teknologi serta dinamika bisnis modern.