Bukan Cuma Clean Architecture: Kenalan Sama 5 Arsitektur yang Mengubah Cara Kita Nulis Kode
Bukan Cuma Clean Architecture: Kenalan Sama 5 Arsitektur yang Mengubah Cara Kita Nulis Kode
Sebelum Clean Architecture ada, lima pikiran besar sudah bergulat dengan masalah yang sama. Ini kisah mereka — siapa pencetusnya, kenapa mereka peduli, dan apa yang bisa kamu pelajari dari masing-masingnya.
💡 Catatan: Artikel ini adalah pelengkap dari seri tutorial implementasi Clean Architecture di Spring Boot. Jika kamu ingin langsung ke kode, baca dulu artikel implementasinya. Kalau kamu ingin tahu mengapa arsitektur itu dirancang seperti itu — kamu ada di tempat yang tepat.
Kalau kamu pernah membuka sebuah proyek lama dan langsung merasa pusing karena kode bisnis bercampur dengan kode database, framework, dan HTTP request di tempat yang sama — maka kamu sudah merasakan sendiri mengapa arsitektur perangkat lunak itu penting.
Artikel ini membahas lima arsitektur besar yang lahir dari keresahan yang sama: bagaimana caranya agar logika bisnis tetap bersih, tidak bergantung pada framework, database, atau teknologi apapun. Kelima arsitektur ini kemudian disatukan oleh Robert C. Martin dalam satu gagasan besar yang disebut Clean Architecture.
Latar Belakang: Mengapa Arsitektur Ini Lahir?
Sebelum masuk ke masing-masing arsitektur, penting untuk memahami masalah yang mereka coba selesaikan.
Pada era 1990-an hingga 2000-an, arsitektur yang paling umum dipakai adalah Layered Architecture (berlapis): Presentation → Business Logic → Data Access. Di atas kertas terlihat rapi. Tapi dalam praktiknya, batas antar layer mudah bocor. Kode SQL muncul di controller. Objek domain berisi anotasi framework. Logika bisnis bergantung pada cara data disimpan di database.
Akibatnya: aplikasi sulit dites, sulit diubah, dan semakin lama semakin keras untuk dipelihara. Para praktisi mulai mencari cara yang lebih baik.
1. Hexagonal Architecture (Ports & Adapters)
Siapa penemunya?
Alistair Cockburn — seorang konsultan, penulis, dan salah satu penanda tangan Agile Manifesto (2001). Ia mulai mengajarkan konsep ini sejak 1994, mendiskusikannya di WikiWikiWeb sejak 1998, dan akhirnya menuliskannya secara resmi pada 2005 dengan nama Ports and Adapters Architecture. Nama "Hexagonal" lebih populer karena visualisasinya menggunakan segi enam.
Kemudian dipopulerkan lebih luas oleh Steve Freeman dan Nat Pryce dalam buku mereka Growing Object Oriented Software, Guided by Tests (2009), yang menjadikan Hexagonal Architecture sebagai fondasi pendekatan TDD mereka.
Kapan dan di mana dipakai?
Hexagonal Architecture cocok dipakai ketika aplikasi perlu bisa dijalankan dari berbagai arah sekaligus: dari REST API, dari antarmuka CLI, dari test otomatis, bahkan dari aplikasi lain — tanpa mengubah logika inti.
- Aplikasi backend yang perlu diganti database-nya tanpa menyentuh logika bisnis
- Sistem yang perlu diuji secara unit tanpa menyalakan database atau server
- Microservices yang butuh batas yang jelas antara domain dan infrastruktur
Mengapa dipakai?
Cockburn melihat bahwa semua ketergantungan pada teknologi luar (UI, database, API eksternal) pada akhirnya membuat aplikasi rapuh. Solusinya: buat lapisan pelindung di sekeliling logika bisnis, dan paksa semua komunikasi dari/ke luar melalui antarmuka yang terdefinisi.
Bagaimana cara kerjanya?
Ide intinya sederhana: ada dalam (inside) dan luar (outside).
- Port adalah antarmuka (interface) yang mendefinisikan apa yang dibutuhkan oleh aplikasi dari luar, atau apa yang ditawarkan aplikasi ke luar.
- Adapter adalah implementasi konkret yang menghubungkan port dengan teknologi nyata (REST controller, MongoDB repository, dsb).
Cockburn membagi adapter menjadi dua jenis:
- Primary/Driving Adapter: yang memulai interaksi (misalnya: REST controller, CLI, test runner)
- Secondary/Driven Adapter: yang dikendalikan oleh aplikasi (misalnya: database adapter, email service, API eksternal)
Prinsip utamanya: logika bisnis tidak boleh tahu apapun tentang teknologi di luar dirinya.
[ REST Controller ] → [ Port (interface) ] → [ Application Core ]
↓
[ Port (interface) ]
↓
[ MongoDB Adapter ]Tokoh-tokoh terkait
- Alistair Cockburn — penemu, penulis artikel asli 2005
- Steve Freeman & Nat Pryce — popularisasi lewat buku GOOS (2009)
- Juan Manuel Garrido de Paz — co-author buku Hexagonal Architecture Explained (2024) bersama Cockburn
- Kevin Rutherford — salah satu yang mendorong Cockburn meresmikan nama "Ports and Adapters"
2. Onion Architecture
Siapa penemunya?
Jeffrey Palermo — software architect dan konsultan asal Amerika Serikat. Ia memperkenalkan Onion Architecture melalui serangkaian blog post mulai Juli 2008 di jeffreypalermo.com.
Kapan dan di mana dipakai?
Onion Architecture sangat cocok untuk aplikasi dengan domain bisnis yang kompleks, di mana perlu ada pemisahan jelas antara domain model, domain service, dan application service. Banyak dipakai bersama pendekatan Domain-Driven Design (DDD).
Mengapa dipakai?
Palermo melihat bahwa Layered Architecture masih membuat database menjadi pusat dari segalanya. Layer atas bergantung pada layer bawah, dan layer bawah biasanya adalah database. Ia ingin membalik perspektif: domain bisnis yang jadi pusat, bukan database.
Bagaimana cara kerjanya?
Seperti namanya, arsitektur ini divisualisasikan sebagai lingkaran konsentris (seperti bawang). Aturan utamanya: dependensi hanya boleh mengarah ke dalam.
- Lingkaran terdalam: Domain Model (entity, value object) — tidak bergantung pada apapun
- Lingkaran kedua: Domain Services — logika bisnis yang melibatkan lebih dari satu entity
- Lingkaran ketiga: Application Services — mengatur alur use case, mengorkestrasi domain
- Lingkaran terluar: Infrastructure — database, UI, API eksternal, framework
┌─────────────────────────────────┐
│ Infrastructure │
│ ┌─────────────────────────┐ │
│ │ Application Services │ │
│ │ ┌─────────────────┐ │ │
│ │ │ Domain Services │ │ │
│ │ │ ┌───────────┐ │ │ │
│ │ │ │ Domain │ │ │ │
│ │ │ │ Model │ │ │ │
│ │ │ └───────────┘ │ │ │
│ │ └─────────────────┘ │ │
│ └─────────────────────────┘ │
└─────────────────────────────────┘Tokoh-tokoh terkait
- Jeffrey Palermo — penemu, blog series 2008–2013
- Sering dikolaborasikan dengan konsep Domain-Driven Design oleh Eric Evans
3. Screaming Architecture
Siapa penemunya?
Robert C. Martin (dikenal sebagai Uncle Bob) — salah satu penanda tangan Agile Manifesto, penulis buku Clean Code (2008) dan Clean Architecture (2017). Ia menulis tentang Screaming Architecture di blognya pada 2011.
Kapan dan di mana dipakai?
Screaming Architecture bukan sebuah pola teknis, melainkan sebuah filosofi penamaan dan struktur folder. Cocok diterapkan di semua jenis proyek, terutama ketika tim ingin kode bisa langsung dipahami tanpa perlu membaca dokumentasi.
Mengapa dipakai?
Uncle Bob prihatin melihat bahwa kebanyakan proyek "berteriak" tentang framework-nya, bukan tentang bisnis yang dijalankan. Struktur folder controllers/, models/, views/ memberitahu bahwa proyek menggunakan MVC — tapi tidak memberitahu bahwa ini adalah aplikasi e-commerce, sistem klinik, atau aplikasi blog.
Bagaimana cara kerjanya?
Prinsipnya: struktur folder harus mencerminkan domain bisnis, bukan framework.
Bandingkan dua struktur ini:
❌ Berteriak tentang framework:
src/
├── controllers/
├── models/
├── repositories/
└── services/
✅ Berteriak tentang bisnis:
src/
├── article/
├── user/
├── comment/
└── notification/Dengan struktur kedua, siapapun yang membuka proyek langsung tahu ini adalah aplikasi blog — bukan karena membaca dokumentasi, tapi karena arsitekturnya berteriak tentang apa yang dilakukan sistem.
Tokoh-tokoh terkait
- Robert C. Martin (Uncle Bob) — penemu dan penggerak utama
4. DCI (Data, Context, Interaction)
Siapa penemunya?
James O. Coplien (dikenal sebagai Cope) — salah satu tokoh penting dalam komunitas software patterns dan XP. Dan Trygve Reenskaug — ilmuwan komputer asal Norwegia yang juga dikenal sebagai penemu pola MVC (Model-View-Controller) pada 1979. Mereka berdua memperkenalkan DCI sekitar 2008–2009.
Kapan dan di mana dipakai?
DCI lebih cocok untuk sistem di mana perilaku objek berubah tergantung konteks. Misalnya: objek User bisa berperan sebagai Buyer dalam konteks transaksi, tapi berperan sebagai Reviewer dalam konteks ulasan produk.
DCI lebih umum diimplementasikan di bahasa yang mendukung mixins atau open classes seperti Ruby, Scala, atau Smalltalk. Di Java, implementasinya lebih rumit.
Mengapa dipakai?
Coplien dan Reenskaug berpendapat bahwa OOP tradisional menyatukan data dan perilaku secara permanen di dalam kelas. Padahal perilaku sebuah objek sering bergantung pada konteks di mana ia beroperasi. DCI memisahkan keduanya.
Bagaimana cara kerjanya?
DCI membagi sistem menjadi tiga elemen:
- Data — objek domain murni yang hanya menyimpan state (apa sistem adalah)
- Context — skenario atau use case yang sedang dijalankan (apa yang sedang terjadi)
- Interaction — peran (role) yang dimainkan objek data selama context tersebut berlangsung (bagaimana objek berperilaku dalam konteks itu)
Perilaku tidak "dimiliki" permanen oleh sebuah objek — ia dipinjamkan ke objek tersebut saat context berjalan, lalu lepas setelah selesai.
Tokoh-tokoh terkait
- James O. Coplien — co-inventor, penulis buku Lean Architecture
- Trygve Reenskaug — co-inventor, juga penemu MVC
5. BCE (Boundary, Control, Entity)
Siapa penemunya?
Ivar Jacobson — ilmuwan komputer asal Swedia, dikenal sebagai salah satu bapak software engineering modern. Ia adalah penemu Use Case sebagai teknik pemodelan, dan memperkenalkan BCE (awalnya disebut ECB) dalam bukunya Object Oriented Software Engineering: A Use-Case Driven Approach yang terbit pada 1992. Jacobson juga merupakan salah satu dari tiga tokoh di balik UML bersama Grady Booch dan James Rumbaugh.
Kapan dan di mana dipakai?
BCE cocok dipakai ketika desain sistem dimulai dari use case, bukan dari database atau UI. Populer dalam metodologi berbasis UML dan dipakai luas di perusahaan enterprise yang menggunakan pendekatan use-case driven.
Mengapa dipakai?
Jacobson ingin membuat sistem yang bisa berevolusi tanpa merusak bagian lain. Dengan memisahkan objek menjadi tiga jenis yang punya tanggung jawab berbeda, perubahan di satu bagian tidak merembet ke seluruh sistem.
Bagaimana cara kerjanya?
BCE membagi semua objek dalam sistem ke dalam tiga kategori:
- Entity — objek yang menyimpan data bisnis dan aturan bisnis inti. Hidup lama, persisten. Contoh:
Article,User,Order. - Control — objek yang mengatur alur sebuah use case. Ia yang tahu langkah-langkah apa yang perlu dilakukan. Contoh:
CreateArticleUseCase,ProcessOrderControl. - Boundary — objek yang berdiri di batas antara sistem dan dunia luar. Contoh:
ArticleController,ArticleRepoAdapter.
[ Boundary ] → [ Control ] → [ Entity ]
(Controller) (Use Case) (Domain)Tokoh-tokoh terkait
- Ivar Jacobson — penemu BCE dan use case driven approach
- Grady Booch & James Rumbaugh — rekan dalam pengembangan UML
6. Clean Architecture: Menyatukan Semuanya
Siapa penemunya?
Robert C. Martin (Uncle Bob) mempublikasikan Clean Architecture pada 13 Agustus 2012 melalui blog-nya di cleancoder.com, kemudian ditulis lebih lengkap dalam buku Clean Architecture: A Craftsman's Guide to Software Structure and Design (2017).
Uncle Bob bukan sekadar menemukan sesuatu yang baru — ia menyintesis kelima arsitektur di atas menjadi satu kerangka yang kohesif dan bisa langsung diterapkan.
Kapan dan di mana dipakai?
- Aplikasi enterprise atau skala menengah ke besar yang akan berkembang dalam jangka panjang
- Tim yang bekerja secara paralel dan perlu batas yang jelas antar komponen
- Sistem yang kemungkinan besar akan berganti teknologi (database, framework, cloud provider) di masa depan
- Proyek yang membutuhkan test coverage tinggi tanpa bergantung pada infrastruktur
Kurang tepat untuk: proyek kecil/prototype, script sederhana, atau CRUD ringan yang tidak perlu skalabilitas jangka panjang.
Mengapa dipakai?
Uncle Bob merangkumnya dalam satu aturan utama:
"Source code dependencies can only point inwards."
— Robert C. Martin, The Clean Architecture, 2012
Artinya: tidak ada satupun kode di lapisan dalam yang boleh mengetahui keberadaan lapisan di luar dirinya. Domain tidak boleh tahu tentang Spring. Use case tidak boleh tahu tentang MongoDB.
Bagaimana cara kerjanya?
Clean Architecture divisualisasikan sebagai lingkaran konsentris dengan empat lapisan utama:
┌──────────────────────────────────────────────┐
│ Frameworks & Drivers │
│ ┌──────────────────────────────────────┐ │
│ │ Interface Adapters │ │
│ │ ┌──────────────────────────────┐ │ │
│ │ │ Application │ │ │
│ │ │ Business Rules │ │ │
│ │ │ ┌──────────────────────┐ │ │ │
│ │ │ │ Enterprise │ │ │ │
│ │ │ │ Business Rules │ │ │ │
│ │ │ │ (Entities) │ │ │ │
│ │ │ └──────────────────────┘ │ │ │
│ │ └──────────────────────────────┘ │ │
│ └──────────────────────────────────────┘ │
└──────────────────────────────────────────────┘- Entities — aturan bisnis enterprise yang paling umum dan paling tidak berubah.
- Use Cases — aturan bisnis spesifik aplikasi. Mengatur alur kerja untuk mencapai tujuan bisnis tertentu.
- Interface Adapters — mengubah data dari format use case ke format UI atau database, dan sebaliknya.
- Frameworks & Drivers — lapisan paling luar. Framework web, database, UI. Detail teknis yang bisa diganti.
Tokoh-tokoh terkait
- Robert C. Martin (Uncle Bob) — penemu dan promotor utama
- Herberto Graça — menulis analisis mendalam tentang evolusi Clean Architecture dari arsitektur-arsitektur pendahulunya
- Ian Cooper — pembicara NDC yang populer tentang implementasi Clean Architecture
- Steve Smith (Ardalis) — membuat template Clean Architecture untuk .NET yang banyak digunakan
Perbandingan Keenam Arsitektur
| Aspek | Hexagonal | Onion | Screaming | DCI | BCE | Clean |
|---|---|---|---|---|---|---|
| Penemu | Alistair Cockburn | Jeffrey Palermo | Uncle Bob | Coplien & Reenskaug | Ivar Jacobson | Uncle Bob |
| Tahun | 1994 / 2005 | 2008 | 2011 | 2008–2009 | 1992 | 2012 |
| Fokus utama | Isolasi aplikasi dari luar lewat ports | Domain sebagai pusat, bukan DB | Struktur folder mencerminkan bisnis | Perilaku objek berbasis konteks | Pemodelan use case ke objek | Aturan dependensi mengarah ke dalam |
| Visualisasi | Segi enam | Lingkaran konsentris | Struktur folder | Tiga dimensi: D, C, I | Stereotip UML | Lingkaran konsentris |
| Aturan utama | Semua koneksi luar lewat port | Dependensi hanya ke dalam | Folder = domain bisnis | Perilaku = role, bukan kelas | Entity / Control / Boundary | The Dependency Rule |
| Cocok untuk | Microservices, TDD | DDD, domain kompleks | Semua proyek | Sistem role-based | Use-case driven, enterprise | Skala menengah–besar |
| Hubungan dengan Clean | Sumber konsep port/adapter | Sumber lapisan konsentris | Sumber filosofi penamaan | Inspirasi pemisahan data & perilaku | Mapping langsung ke layer Clean | Sintesis semua arsitektur |
Perbedaan Mendasar yang Perlu Dipahami
Hexagonal hanya mengenal dua wilayah: dalam dan luar. Ia tidak menentukan bagaimana struktur internal aplikasi. Onion melangkah lebih jauh dengan memecah bagian dalam menjadi beberapa lapisan yang lebih terperinci (domain model, domain service, application service). Onion adalah Hexagonal yang bagian dalamnya sudah diberi struktur.
Keduanya menggunakan lingkaran konsentris. Perbedaannya: Onion berakar dari DDD dan mengikuti pembagian layer DDD. Clean Architecture lebih generik — ia menggabungkan konsep dari Hexagonal, Onion, BCE, dan DCI, lalu menyederhanakan menjadi empat lapisan dengan satu aturan tegas: The Dependency Rule.
Mapping-nya hampir satu-satu: BCE Entity = Clean Entities layer, BCE Control = Clean Use Cases layer, BCE Boundary = Clean Interface Adapters layer. Perbedaannya: BCE lahir dari pendekatan UML dan use-case modeling, sedangkan Clean Architecture lebih luas dan bisa diterapkan tanpa UML.
DCI adalah yang paling berbeda. Arsitektur lain fokus pada di mana kode diletakkan. DCI fokus pada bagaimana objek mendapatkan perilakunya. DCI bukan tentang folder atau layer, melainkan tentang runtime assignment of roles. Ia lebih cocok sebagai paradigma pemrograman daripada arsitektur sistem secara keseluruhan.
Screaming Architecture bukan arsitektur mandiri — ia adalah prinsip penamaan yang bisa diterapkan di atas arsitektur manapun. Ia menjawab pertanyaan: "Bagaimana kita mengorganisasi file dan folder?" bukan "Bagaimana dependensi mengalir?"
Kesimpulan: Satu Tujuan, Banyak Jalan
Kelima arsitektur ini lahir dari keresahan yang sama dan menuju ke tujuan yang sama. Uncle Bob merangkumnya dengan baik:
"Though these architectures all vary somewhat in their details, they are very similar. They all have the same objective, which is the separation of concerns."
— Robert C. Martin, The Clean Architecture, 2012
Sistem yang dibangun dengan salah satu dari arsitektur ini akan memiliki sifat-sifat berikut:
- Independent of Frameworks — framework adalah alat, bukan penjara
- Testable — logika bisnis bisa dites tanpa database, UI, atau server
- Independent of UI — UI bisa diganti tanpa mengubah logika bisnis
- Independent of Database — bisa pindah dari MongoDB ke PostgreSQL tanpa menyentuh domain
- Independent of External Services — integrasi eksternal bisa diganti kapan saja
Jika kamu sudah membaca artikel sebelumnya tentang implementasi Clean Architecture di Spring Boot, kamu bisa melihat langsung bagaimana konsep-konsep dari kelima arsitektur ini hidup bersama dalam satu project:
ArticleRepository(interface di domain) — Port dari HexagonalArticleRepoAdapter— Adapter dari Hexagonaldomain/,usecase/,adapter/— Lingkaran Onion & lapisan Clean Architecture- Struktur folder yang bicara tentang bisnis, bukan framework — Screaming Architecture
Article.java= Entity,CreateArticleUseCase.java= Control,ArticleController.java= Boundary — BCE
Tidak ada yang namanya "satu arsitektur terbaik untuk semua kasus." Yang ada adalah arsitektur yang tepat untuk konteks dan kebutuhan proyekmu. Memahami asal-usul dan tujuan dari masing-masing arsitektur ini akan membantumu membuat keputusan yang lebih baik saat merancang sistem berikutnya.
Referensi
- Robert C. Martin, The Clean Architecture, cleancoder.com, 13 Agustus 2012
- Alistair Cockburn, Hexagonal Architecture, alistair.cockburn.us, 2005
- Jeffrey Palermo, The Onion Architecture, jeffreypalermo.com, 2008
- Ivar Jacobson, Object Oriented Software Engineering: A Use-Case Driven Approach, 1992
- Steve Freeman & Nat Pryce, Growing Object Oriented Software, Guided by Tests, 2009
- Herberto Graça, Clean Architecture: Standing on the Shoulders of Giants, herbertograca.com, 2017
Comments
Post a Comment