Clean Architecture #

Dalam pengembangan software modern, kompleksitas aplikasi terus meningkat: kebutuhan bisnis berubah cepat, teknologi berganti, dan tim berkembang. Tanpa arsitektur yang baik, kode akan sulit dirawat (maintain), diuji (test), dan dikembangkan (extend).

Clean Architecture hadir sebagai pendekatan arsitektur yang berfokus pada pemisahan tanggung jawab (separation of concerns) dan ketergantungan yang terkontrol. Tujuannya adalah membuat sistem yang mudah diuji, fleksibel terhadap perubahan teknologi, dan berumur panjang.

Berbeda dengan sekadar pattern, Clean Architecture adalah mindset dalam menyusun struktur aplikasi.

Bagan Clean Architecture (Text-Based) #

Berikut ilustrasi Clean Architecture secara konseptual dalam bentuk teks:

+--------------------------------------------------+
|                  Frameworks & Drivers            |
|  (Web, UI, DB, External APIs, Messaging, etc)    |
+-------------------------↑------------------------+
|                  Interface Adapters              |
|   (Controllers, Presenters, Gateways, DTO)       |
+-------------------------↑------------------------+
|                  Application / Use Cases         |
|        (Business Rules Aplikasi)                 |
+-------------------------↑------------------------+
|                       Entities                   |
|        (Enterprise Business Rules)               |
+--------------------------------------------------+

        Arah dependency selalu ke dalam (inward)

Prinsip utamanya:

Kode di layer dalam tidak boleh bergantung pada layer luar.

Apa itu Clean Architecture? #

Clean Architecture adalah konsep arsitektur yang dipopulerkan oleh Robert C. Martin (Uncle Bob). Arsitektur ini menyatukan ide-ide terbaik dari:

• Hexagonal Architecture
• Onion Architecture
• Ports and Adapters

Fokus utamanya adalah aturan dependency dan isolasi business logic dari detail teknis seperti database, framework, dan UI.

Dalam Clean Architecture:

• Business logic adalah pusat sistem
• Framework hanyalah alat, bukan fondasi

Tujuan Architecture #

Tujuan utama Clean Architecture adalah:

1. Independence of Frameworks Aplikasi tidak terikat pada framework tertentu (Gin, Fiber, Spring, Laravel, dll).

2. Testability Business logic bisa diuji tanpa database, server, atau UI.

3. Independence of UI UI bisa berubah (REST → GraphQL → gRPC) tanpa mengubah core logic.

4. Independence of Database Database dianggap detail implementasi, bukan pusat aplikasi.

5. Maintainability & Scalability Kode lebih rapi, mudah dipahami, dan siap berkembang jangka panjang.

Kapan Cocok Digunakan? #

Clean Architecture cocok digunakan ketika:

• Aplikasi berskala menengah hingga besar
• Sistem memiliki business rules yang kompleks
• Proyek diprediksi memiliki umur panjang
• Tim terdiri dari banyak developer
• Dibutuhkan testing yang kuat (unit test & integration test)

Kurang cocok jika:

• Proyek sangat kecil atau prototipe cepat
• Deadline sangat ketat dengan scope minimal
• Aplikasi hanya CRUD sederhana dan tidak akan berkembang

Pros dan Cons #

✅ Pros #

1. Struktur kode jelas dan konsisten
2. Business logic terlindungi dari perubahan teknis
3. Mudah diuji (testable by design)
4. Framework-agnostic
5. Cocok untuk long-term project

❌ Cons #

1. Learning curve cukup tinggi bagi pemula
2. Boilerplate code lebih banyak
3. Overengineering jika dipakai untuk proyek kecil
4. Membutuhkan disiplin tim agar aturan dependency tidak dilanggar

Kesalahan Umum #

• Menjadikan Entity sebagai “God Object”
• Use Case terlalu kecil atau terlalu besar
• Framework masih “bocor” ke layer dalam
• Terlalu banyak abstraction tanpa manfaat nyata

Best Practice #

1. Jaga Dependency Rule #

• Entities tidak boleh tahu tentang Use Case, DB, atau framework
• Use Case tidak boleh bergantung pada framework

2. Gunakan Interface untuk Boundary #

Contoh:

• UserRepository sebagai interface
• Implementasi DB (PostgresUserRepository) ada di layer luar

3. Hindari Logic di Controller #

Controller hanya bertugas:

• Validasi request
• Mapping DTO
• Memanggil use case

Business logic harus berada di Use Case atau Entities.

4. Pisahkan Model Domain dan Model Transport #

• Jangan gunakan struct DB langsung sebagai entity
• Gunakan DTO untuk komunikasi antar layer

5. Jangan Terlalu Fanatik #

Clean Architecture adalah guideline, bukan agama.

• Adaptasi sesuai konteks
• Tidak semua aturan harus diterapkan 100%

Penutup #

Clean Architecture bukan tentang folder atau naming, melainkan tentang cara berpikir dalam membangun software yang sehat. Dengan memusatkan perhatian pada business rules dan mengontrol dependency, kita bisa menghasilkan aplikasi yang:

• Mudah dirawat
• Mudah diuji
• Siap menghadapi perubahan teknologi

Gunakan Clean Architecture secara bijak. Terapkan saat kompleksitas memang membutuhkannya, dan sederhanakan saat konteks menuntut kecepatan.

“The goal of software architecture is to minimize the human resources required to build and maintain the required system.” — Robert C. Martin