Clean Code Bukan Clean Architecture: Meluruskan Kebingungan Terminologi Hexagonal, Onion, dan Port–Adapter
Memahami Clean Architecture
Tanpa Kebingungan
Port, Adapter, Hexagonal, Onion — semua istilah ini membicarakan satu prinsip yang sama.
Banyak developer mencoba memahami arsitektur modern dengan menghafal struktur folder atau istilah baru, tanpa benar-benar memahami hubungan antar konsepnya. Padahal jika dilihat lebih dekat, sebagian besar konsep ini sebenarnya cukup sederhana — kebingungan sering muncul bukan karena konsepnya rumit, tetapi karena istilah yang digunakan berbeda-beda.
Clean Code: Fokus pada Kualitas Kode
Salah satu sumber kebingungan yang paling umum adalah anggapan bahwa Clean Code dan Clean Architecture adalah konsep yang sama. Padahal keduanya membahas hal yang berbeda.
Istilah Clean Code menjadi populer melalui buku Clean Code karya Robert C. Martin. Fokus utamanya: bagaimana menulis kode yang mudah dibaca, mudah dipahami, dan mudah dirawat oleh developer lain.
Prinsip-prinsip Clean Code
- Menggunakan nama variabel dan fungsi yang jelas dan bermakna
- Membuat fungsi kecil dengan satu tanggung jawab
- Menghindari duplikasi kode
- Menjaga struktur kode tetap sederhana dan konsisten
- Menerapkan prinsip desain seperti SOLID
Dengan kata lain, Clean Code lebih banyak berbicara tentang kualitas kode pada level function, class, dan file.
⚠️ Penting: Clean Code tidak membahas bagaimana keseluruhan sistem disusun. Ia tidak menentukan bagaimana aplikasi harus dibagi menjadi layer, bagaimana modul berinteraksi, atau bagaimana business logic dipisahkan dari teknologi tertentu.
Di sinilah konsep arsitektur aplikasi mulai berperan — dan di situlah kita masuk ke pembahasan Clean Architecture.
Clean Architecture: Fokus pada Struktur Sistem
Jika Clean Code membahas bagaimana menulis kode yang baik, maka Clean Architecture membahas sesuatu yang berbeda: bagaimana menyusun struktur sebuah sistem aplikasi.
Konsep ini dipopulerkan oleh Robert C. Martin dalam bukunya Clean Architecture: A Craftsman's Guide to Software Structure and Design.
Bagaimana menulis kode yang baik — fokus di level fungsi, class, dan file.
Bagaimana menyusun sistem dengan baik — fokus pada struktur dan layer aplikasi.
Pertanyaan yang Dijawab Clean Architecture
- Di mana sebaiknya business logic ditempatkan?
- Bagaimana cara memisahkan domain bisnis dari framework atau database?
- Bagaimana agar sistem tetap mudah berubah ketika teknologi di sekitarnya berubah?
Lapisan dalam Clean Architecture
- Domain — berisi aturan bisnis inti
- Use Case — mengatur alur atau proses aplikasi
- Interface Adapter — menjembatani antara sistem dan dunia luar
- Infrastructure — teknologi seperti database, framework, atau API
⚠️ Tujuan pembagian ini bukan sekadar membuat struktur folder baru. Tujuannya adalah menjaga agar business logic tetap terisolasi dari perubahan teknologi.
Hexagonal, Onion & Clean: Apakah Berbeda?
Setelah memahami Clean Architecture, developer biasanya menemukan istilah lain yang tampak seperti arsitektur baru. Banyak yang bertanya: "Haruskah saya memilih salah satu dari tiga arsitektur ini?"
Padahal jika kita melihat tujuan dan prinsip dasarnya, ketiganya sebenarnya membicarakan ide yang sangat mirip.
Diperkenalkan oleh Alistair Cockburn. Core di tengah, dunia luar berinteraksi lewat port, implementasi teknis oleh adapter.
Diperkenalkan oleh Jeffrey Palermo. Sistem seperti lapisan bawang — domain di pusat, dependency selalu ke dalam.
Dipopulerkan oleh Robert C. Martin. Menyatukan berbagai ide dalam lingkaran konsentris: Entities → Use Cases → Adapters → Framework.
Kesimpulan: Prinsip yang Sama
- Business logic berada di pusat sistem
- Detail teknologi berada di luar
- Dependency selalu mengarah ke inti aplikasi
Port & Adapter: Konsep yang Sering Terlihat Rumit
Istilah ini sering terdengar rumit, padahal konsep dasarnya cukup sederhana. Cara paling mudah memahaminya adalah dengan melihat peran masing-masing.
Apa itu Port?
Port adalah kontrak atau interface yang menjelaskan bagaimana sistem bisa digunakan atau bagaimana sistem berinteraksi dengan sesuatu. Dalam Java, port biasanya berupa interface. Port tidak berisi detail teknologi — ia hanya mendefinisikan apa yang bisa dilakukan, bukan bagaimana cara melakukannya.
public interface ArticleRepository { Article save(Article article); Optional<Article> findById(String id); }
Interface ini mendefinisikan kemampuan sistem tanpa menyebutkan apakah datanya disimpan di MongoDB, MySQL, Redis, atau API eksternal. Semua itu adalah detail implementasi.
Apa itu Adapter?
Jika port adalah kontrak, maka adapter adalah implementasi dari kontrak tersebut. Adapter menghubungkan sistem dengan dunia luar: database, REST API, message broker, email sender, dan sebagainya.
@Repository public class MongoArticleRepository implements ArticleRepository { private final SpringDataArticleRepository repository; @Override public Article save(Article article) { return repository.save(article); } @Override public Optional<Article> findById(String id) { return repository.findById(id); } }
Satu Port, Banyak Adapter
Satu port tidak terikat pada satu teknologi. Kita bisa memiliki beberapa adapter untuk port yang sama.
ArticleRepository (Port) ├── MongoArticleRepository // MongoDB ├── MysqlArticleRepository // MySQL └── InMemoryArticleRepository // untuk testing
- Mudah mengganti database tanpa menyentuh business logic
- Mudah membuat mock untuk unit testing
- Sistem menjadi lebih fleksibel dan mudah dirawat
Driving Adapter vs Driven Adapter
Driving Adapter — Dunia Luar → Sistem
Driving adapter adalah komponen yang memulai interaksi dengan sistem kita. Contohnya: HTTP Controller, REST API endpoint, CLI command, atau message consumer.
@RestController public class ArticleController { private final CreateArticleUseCase useCase; @PostMapping("/articles") public Article create(@RequestBody CreateArticleRequest request) { return useCase.execute(request); } }
Driven Adapter — Sistem → Dunia Luar
Driven adapter adalah komponen yang dipanggil oleh sistem untuk berkomunikasi dengan dunia luar. Contohnya: repository database, client API eksternal, email sender, atau message producer.
Dunia luar memanggil sistem kita → pintu masuk
Sistem kita memanggil dunia luar → pintu keluar
Folder adapter/in & adapter/out
Setelah memahami Port dan Adapter, biasanya developer melihat struktur folder seperti ini pada proyek Clean Architecture dan bertanya: "Apa sebenarnya arti in dan out di sini?"
Jawabannya sederhana jika dihubungkan dengan konsep Driving Adapter dan Driven Adapter.
- REST Controller
- GraphQL Resolver
- CLI Command Handler
- Message Queue Consumer
- Database Repository
- External API Client
- Email Sender
- Message Queue Producer
src/
└── adapter/
├── in/
│ └── web/
│ └── ArticleController.java // Driving Adapter
└── out/
└── persistence/
└── MongoArticleRepository.java // Driven Adapter
💡 Struktur adapter/in dan adapter/out bukan aturan wajib. Ini hanyalah konvensi yang membantu developer memahami arah aliran data dengan cepat. Tujuan utamanya tetap: menjaga business logic bersih dan terpisah dari detail teknologi.
Domain, Entity & Model: Di Mana Posisinya?
Setelah memahami Port dan Adapter, biasanya muncul pertanyaan berikutnya: "Di mana sebenarnya posisi Domain, Entity, dan Model di dalam arsitektur ini?"
Kebingungan ini wajar karena dalam berbagai artikel, ketiga istilah tersebut sering digunakan secara bergantian, padahal konteksnya bisa berbeda.
Domain: Inti dari Sistem
Domain adalah bagian paling inti dari sistem — berisi aturan bisnis utama yang menjadi alasan mengapa sistem tersebut dibuat. Domain tidak boleh bergantung pada framework, database, atau teknologi apa pun.
Entity: Representasi Objek Bisnis
Di dalam domain biasanya terdapat entity — objek yang merepresentasikan konsep bisnis penting dan memiliki identitas yang unik.
public class Article { private String id; private String title; private String content; public void publish() { // aturan bisnis publikasi di sini } }
Lalu Apa itu Model?
Istilah model sering digunakan sebagai istilah umum. Dalam proyek Java, satu kata "model" bisa merujuk ke beberapa hal yang berada di lapisan berbeda.
Article // Domain Entity — objek bisnis dalam domain ArticleRequest // DTO — transfer data dari/ke API ArticleDocument // Persistence — model yang dipetakan ke MongoDB
Posisi Domain dalam Keseluruhan Arsitektur
- Domain berada di pusat sistem — tidak tahu apa-apa tentang detail teknologi
- Dependency selalu mengarah ke dalam — ini disebut Dependency Rule
- Teknologi berada di lapisan paling luar — mudah diganti tanpa merusak inti
Penutup: Satu Prinsip, Banyak Nama
Semua istilah yang membingungkan itu sebenarnya hanya menjelaskan satu hal yang sama:
Inti dari semua pendekatan ini sebenarnya sama: menjaga agar business logic tetap berada di pusat sistem dan tidak bergantung pada detail teknologi.
Ketika konsep ini sudah dipahami, berbagai istilah seperti Port, Adapter, atau perbedaan antara Hexagonal, Onion, dan Clean Architecture tidak lagi terasa membingungkan — semuanya hanyalah cara berbeda untuk menjelaskan prinsip yang sama.
Comments
Post a Comment