Oksa Satya.

24 Juni 2026 · 8 menit baca

Arsitektur Hexagonal di Go: Kenapa Domain Tidak Boleh Tahu Soal Database

GoArsitekturHexagonalClean Architecture

Banyak developer mendengar 'hexagonal' lalu membayangkan diagram rumit dan banyak folder. Padahal intinya satu kalimat: aturan bisnis tidak boleh tahu dari mana datanya datang. Ini alasan kenapa disiplin itu terbayar di sistem production seperti Dexova, dan bagaimana menerapkannya di Go tanpa berlebihan.

Arah dependensi yang mengalir ke dalam

Aturannya cuma satu dan keras: lapisan domain tidak mengimpor apa pun dari adapter atau platform. Domain mendefinisikan port (interface) yang ia butuhkan — mis. sebuah repository — dan lapisan luar yang mengimplementasikannya dengan pgx atau apa pun.

Efeknya: use-case bisa diuji dengan implementasi port palsu di memori, tanpa PostgreSQL, tanpa jaringan. Uji payroll jadi soal menyiapkan input dan memeriksa output — bukan menyiapkan seluruh infrastruktur.

Port adalah kontrak milik domain

Kesalahan umum: mendefinisikan interface repository di paket adapter, 'dekat' dengan implementasinya. Itu membalik arah dependensi. Port adalah kebutuhan domain, jadi ia hidup di domain; adapter yang menyesuaikan diri, bukan sebaliknya.

Di Go ini terasa alami karena interface bersifat implicit — domain mendeklarasikan interface kecil sesuai kebutuhannya, dan adapter cukup memenuhinya. Interface yang ramping (satu-dua method) jauh lebih mudah di-mock daripada repository raksasa serba bisa.

Jangan over-engineer: hexagonal-lite

Hexagonal tidak berarti CQRS, event sourcing, dan tujuh lapisan abstraksi untuk CRUD sederhana. Untuk solo/tim kecil, cukup: domain (entity + port + use-case) yang murni, adapter (DB, HTTP, pihak ketiga), dan composition root yang merakit semuanya.

Tanda over-engineering: interface dengan satu implementasi yang tidak akan pernah punya kedua, factory untuk satu produk, abstraksi 'untuk nanti'. Aturannya: tambahkan lapisan saat rasa sakitnya nyata, bukan saat membayangkannya.

Ringkasan

Hexagonal terbayar bukan karena diagramnya indah, tapi karena membuat aturan bisnis bisa diuji cepat dan infrastruktur bisa ditukar tanpa drama. Jaga arah dependensi mengalir ke domain, biarkan port jadi milik domain, dan berhenti di lapisan seminimal yang menyelesaikan masalah.

Sedang membangun sistem serupa?

Saya menerima proyek dan konsultasi teknis seputar sistem bisnis.