Onion Architecture #

Dalam pengembangan aplikasi skala menengah hingga besar, tantangan utama bukan hanya membuat fitur berjalan, tetapi menjaga kode tetap terstruktur, mudah diuji, dan mudah dikembangkan dalam jangka panjang. Banyak aplikasi gagal bukan karena kurang fitur, melainkan karena arsitekturnya sulit dirawat.

Onion Architecture hadir sebagai salah satu pendekatan arsitektur yang menekankan separation of concerns dan dependency inversion, sehingga business logic benar-benar terisolasi dari detail teknis seperti database, framework, atau UI.

Berikut gambaran Onion Architecture dalam bentuk bagan text-based:

+--------------------------------------------------+
|                Infrastructure Layer              |
|  (DB, ORM, HTTP, Framework, External Services)   |
+--------------------------------------------------+
            ↑ depends on abstractions
+--------------------------------------------------+
|                Application Layer                 |
|     (Use Case / Service / Interactor)            |
+--------------------------------------------------+
            ↑ depends on abstractions
+--------------------------------------------------+
|                    Domain Layer                  |
|   (Entity, Value Object, Domain Service)         |
+--------------------------------------------------+

Prinsip utamanya sederhana namun kuat:

Dependency selalu mengarah ke dalam (ke domain), bukan sebaliknya.

Apa itu Onion Architecture? #

Onion Architecture adalah pola arsitektur aplikasi yang diperkenalkan oleh Jeffrey Palermo. Arsitektur ini memusatkan desain pada domain (business rules) sebagai inti aplikasi.

Lapisan paling dalam (Domain) tidak mengetahui apa pun tentang:

• Database apa yang digunakan
• Framework web apa yang dipakai
• Cara data dikirim (HTTP, gRPC, CLI, dll)

Sebaliknya, detail teknis berada di lapisan luar dan bergantung pada kontrak (interface) yang didefinisikan di lapisan dalam.

Struktur Layer pada Onion Architecture #

Domain Layer (Core) #

Lapisan paling inti dan paling penting.

Berisi:

• Entity (business object utama)
• Value Object
• Domain Service
• Interface repository (abstraction)

Ciri utama:

• Tidak bergantung pada framework
• Tidak tahu cara data disimpan
• Mudah diuji (pure logic)

Application Layer #

Lapisan yang mengatur use case aplikasi.

Berisi:

• Use Case / Interactor
• Application Service
• DTO (opsional)

Tugas utama:

• Mengorkestrasi alur bisnis
• Memanggil domain
• Menggunakan repository via interface

Application layer tidak berisi logic bisnis kompleks, melainkan flow.

Infrastructure Layer #

Lapisan terluar yang berisi detail teknis.

Contoh isi:

• Implementasi repository (DB, ORM)
• HTTP handler / controller
• Framework (Gin, Fiber, Echo, Spring, dll)
• External service (Redis, Kafka, API pihak ketiga)

Lapisan ini boleh berubah, selama kontrak ke dalam tetap sama.

Tujuan Architecture #

Tujuan utama Onion Architecture adalah:

1. Melindungi business logic dari perubahan teknis
2. Meningkatkan maintainability
3. Mempermudah testing (unit test tanpa DB/framework)
4. Mengurangi coupling antar komponen
5. Mendukung evolusi aplikasi jangka panjang

Dengan kata lain: framework adalah detail, domain adalah raja.

Kapan Cocok Digunakan? #

Onion Architecture sangat cocok jika:

✅ Aplikasi memiliki business rule yang kompleks ✅ Proyek diproyeksikan hidup lama (long-term project) ✅ Tim cukup besar atau akan berkembang ✅ Perubahan teknologi di masa depan sangat mungkin ✅ Ingin test coverage yang kuat di level domain

Kurang cocok jika:

❌ Aplikasi sangat kecil / throwaway project ❌ Hanya CRUD sederhana tanpa logic berarti ❌ Time-to-market sangat ketat dan tim kecil

Pros dan Cons #

✅ Pros #

1. Business logic terisolasi dengan baik
2. High testability (domain bisa diuji tanpa mock berat)
3. Framework-agnostic
4. Scalable secara struktur dan tim
5. Lebih tahan terhadap perubahan teknologi

❌ Cons #

1. Struktur awal terasa kompleks
2. Boilerplate bertambah (interface, mapper, dll)
3. Learning curve untuk tim baru
4. Overkill untuk aplikasi sederhana

Informasi Tambahan yang Perlu Diketahui #

• Onion Architecture sering disandingkan dengan:

  • Clean Architecture (Robert C. Martin)
  • Hexagonal Architecture (Ports & Adapters)

• Perbedaannya lebih pada istilah dan penekanan, prinsip dasarnya hampir sama:

  Dependency inversion dan isolasi domain.

• Di Golang, Onion Architecture sangat cocok karena:

  • Interface adalah first-class citizen
  • Package-based modularity sangat fleksibel

Best Practices #

1. Domain harus benar-benar bersih Jangan import package framework apa pun di domain layer.

2. Gunakan interface untuk dependency keluar Repository dan external service didefinisikan di domain atau application layer.

3. Application layer fokus pada use case Hindari logic bisnis kompleks di controller atau handler.

4. Infrastructure hanya implementasi, bukan decision maker Infrastructure tidak boleh menentukan aturan bisnis.

5. Pisahkan model domain dan model persistence Jangan mencampur entity domain dengan ORM annotation jika memungkinkan.

6. Test domain tanpa database Ini adalah indikator Onion Architecture diterapkan dengan benar.

Penutup #

Onion Architecture bukan solusi untuk semua masalah, tetapi sangat efektif untuk aplikasi yang serius secara bisnis dan umur proyek. Dengan menempatkan domain sebagai pusat, kita membangun sistem yang lebih tahan terhadap perubahan, lebih mudah diuji, dan lebih nyaman dirawat.

Jika aplikasi Anda terus berkembang, logic makin kompleks, dan tim makin besar—Onion Architecture adalah investasi arsitektur yang layak dipertimbangkan.

Bangun aplikasi yang framework-nya bisa diganti, tanpa harus mengganti logika bisnis.