Pernah develop sebuah fitur, sudah selesai, lalu pas demo ke client mereka bilang “ini bukan yang dimaksud”? Padahal kita sudah implementasi sesuai yang dibilang di meeting.

Atau pernah ngerasa aneh waktu kode kita punya User tapi bisnis menyebutnya Member, atau kita punya Transaction tapi bisnis bilang Order? Kecil memang — tapi lama-lama ini jadi sumber miskomunikasi yang serius.

Nah, Domain-Driven Design (DDD) hadir untuk masalah ini. Bukan sekedar cara nulis kode, tapi cara berpikir dan berkomunikasi tentang sistem yang kita bangun.

Apa Itu DDD?

Domain-Driven Design adalah pendekatan pengembangan software yang dipopulerkan oleh Eric Evans lewat bukunya Domain-Driven Design: Tackling Complexity in the Heart of Software (2003). Sampai sekarang masih relevan, bahkan makin banyak dipakai di era microservices.

Ide utamanya: software harus mencerminkan domain bisnis yang ia modelkan. Model kode kita harus sedekat mungkin dengan cara bisnis berpikir dan berbicara.

Domain sendiri artinya area masalah yang sedang kita selesaikan. Contoh:

• Aplikasi e-commerce → domain: penjualan, inventori, pengiriman, pembayaran
• Sistem HR → domain: penggajian, absensi, rekrutmen, evaluasi
• Platform fintech → domain: pengajuan kredit, penilaian risiko, penagihan, compliance

DDD cocok untuk sistem dengan domain yang kompleks — banyak aturan bisnis, banyak stakeholder, dan logic yang terus berkembang. Untuk CRUD sederhana, ini overkill.

Konsep Inti DDD

1. Ubiquitous Language — Satu Bahasa, Satu Tim

Ini adalah fondasi dari segalanya. Ubiquitous Language artinya developer dan domain expert (orang bisnis, product manager, dsb) harus menggunakan terminologi yang persis sama.

Kalau bisnis bilang “pengajuan kredit disetujui oleh credit analyst”, maka di kode harus ada:

// ✅ Mencerminkan bahasa bisnis
type CreditApplication struct {
    ID         string
    ApplicantID string
    Status      ApplicationStatus
    ReviewedBy  *CreditAnalyst
    ApprovedAt  *time.Time
}

func (a *CreditApplication) Approve(analyst CreditAnalyst) error {
    if a.Status != StatusUnderReview {
        return ErrCannotApprove
    }
    a.Status = StatusApproved
    a.ReviewedBy = &analyst
    now := time.Now()
    a.ApprovedAt = &now
    return nil
}

Bukan:

// ❌ Bahasa teknis, developer-centric
func (r *Record) UpdateFlag(statusCode int, reviewerUID string) {}

Ubiquitous Language harus konsisten di semua tempat: nama class, nama method, nama tabel database, bahkan nama variable. Ketika ada meeting, kamu bisa buka kode dan semua orang di ruangan itu paham maksudnya.

2. Bounded Context — Batas yang Jelas

Sistem besar tidak bisa punya satu model tunggal untuk semua hal. Kata yang sama bisa punya arti berbeda di konteks yang berbeda.

Ambil contoh kata “Produk” di sistem e-commerce:

• Di Katalog: Produk punya nama, foto, deskripsi, kategori, tag
• Di Inventori: Produk punya SKU, stok, lokasi gudang, reorder point
• Di Pengiriman: Produk punya berat, dimensi, fragile atau tidak

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│ Bounded Context │    │ Bounded Context │    │ Bounded Context │
│    Katalog      │    │   Inventori     │    │   Pengiriman    │
│                 │    │                 │    │                 │
│ Product:        │    │ StockItem:      │    │ Shipment:       │
│ - name          │    │ - sku           │    │ - productRef    │
│ - description   │    │ - quantity      │    │ - weight        │
│ - images        │    │ - warehouseLoc  │    │ - dimensions    │
│ - category      │    │ - reorderPoint  │    │ - isFragile     │
└─────────────────┘    └─────────────────┘    └─────────────────┘
         │                      │                      │
         └──────────────────────┴──────────────────────┘
                    Komunikasi lewat events / API

Setiap Bounded Context punya model sendiri, mungkin database sendiri, dan idealnya tim sendiri. Ini adalah batas alami kalau kita mau pisah ke microservices nantinya.

Kenapa ini penting? Karena kalau dipaksakan satu model untuk semua konteks, model itu akan jadi semakin kompleks dan membingungkan. Lebih baik punya beberapa model yang sederhana dan jelas daripada satu model yang serba bisa tapi susah dipahami.

3. Entity — Objek dengan Identitas

Entity adalah objek yang punya identitas unik yang persisten sepanjang hidupnya. Dua Entity dengan data yang sama tapi ID berbeda = dua objek yang berbeda.

type Customer struct {
    ID    CustomerID
    Name  string
    Email Email
    Phone string
    Tier  MemberTier
}

// Customer A dan Customer B dengan nama "Budi Santoso" adalah dua orang berbeda
// karena mereka punya ID yang berbeda

Identitas Entity tidak berubah meski atributnya berubah. Customer yang ganti nama atau pindah alamat tetap Customer yang sama — karena ID-nya sama.

4. Value Object — Objek Tanpa Identitas

Value Object tidak punya identitas. Dua Value Object dengan nilai yang sama dianggap identik. Value Object sebaiknya immutable — kalau mau “mengubah” nilainya, buat object baru.

type Money struct {
    Amount   float64
    Currency string
}

// Money{50000, "IDR"} == Money{50000, "IDR"} → dianggap sama
// Money{50000, "IDR"} != Money{50000, "USD"} → berbeda

// Immutable — operasi menghasilkan object baru
func (m Money) Add(other Money) (Money, error) {
    if m.Currency != other.Currency {
        return Money{}, errors.New("currency tidak sama")
    }
    return Money{
        Amount:   m.Amount + other.Amount,
        Currency: m.Currency,
    }, nil
}

func (m Money) Subtract(other Money) (Money, error) {
    if m.Currency != other.Currency {
        return Money{}, errors.New("currency tidak sama")
    }
    if m.Amount < other.Amount {
        return Money{}, errors.New("saldo tidak cukup")
    }
    return Money{
        Amount:   m.Amount - other.Amount,
        Currency: m.Currency,
    }, nil
}

Contoh Value Object lain yang sering dipakai: Email, PhoneNumber, Address, DateRange, Coordinate, Price.

Kenapa perlu Value Object? Karena kalau kita pakai string untuk email, tidak ada yang mencegah kita isi dengan nilai sembarang. Value Object memaksa validasi dilakukan di satu tempat.

type Email struct {
    value string
}

func NewEmail(raw string) (Email, error) {
    if !isValidEmail(raw) {
        return Email{}, errors.New("format email tidak valid")
    }
    return Email{value: strings.ToLower(raw)}, nil
}

func (e Email) String() string { return e.value }

5. Aggregate — Satu Pintu Masuk

Aggregate adalah kumpulan Entity dan Value Object yang diperlakukan sebagai satu unit dalam hal perubahan data. Setiap Aggregate punya satu Aggregate Root — satu-satunya titik akses untuk semua operasi.

Contoh: Order sebagai Aggregate Root yang mengandung beberapa OrderItem.

// Order adalah Aggregate Root
type Order struct {
    id          OrderID
    customerID  CustomerID
    items        []OrderItem    // OrderItem adalah Entity di dalam Aggregate
    status       OrderStatus
    totalAmount  Money
    createdAt    time.Time
}

// Semua perubahan HARUS melalui Aggregate Root
func (o *Order) AddItem(product Product, quantity int) error {
    if o.status != StatusDraft {
        return errors.New("item hanya bisa ditambah saat status masih draft")
    }

    // Cek apakah produk sudah ada di order
    for i, item := range o.items {
        if item.ProductID == product.ID {
            o.items[i].Quantity += quantity
            o.recalculateTotal()
            return nil
        }
    }

    o.items = append(o.items, OrderItem{
        ProductID: product.ID,
        Name:      product.Name,
        Price:     product.Price,
        Quantity:  quantity,
    })
    o.recalculateTotal()
    return nil
}

func (o *Order) RemoveItem(productID ProductID) error {
    if o.status != StatusDraft {
        return errors.New("item hanya bisa dihapus saat status masih draft")
    }
    for i, item := range o.items {
        if item.ProductID == productID {
            o.items = append(o.items[:i], o.items[i+1:]...)
            o.recalculateTotal()
            return nil
        }
    }
    return errors.New("item tidak ditemukan")
}

func (o *Order) Confirm() error {
    if o.status != StatusDraft {
        return errors.New("hanya order berstatus draft yang bisa dikonfirmasi")
    }
    if len(o.items) == 0 {
        return errors.New("tidak bisa konfirmasi order kosong")
    }
    o.status = StatusConfirmed
    return nil
}

// Private — hanya bisa dipanggil dari dalam Aggregate
func (o *Order) recalculateTotal() {
    total := Money{Currency: "IDR"}
    for _, item := range o.items {
        subtotal, _ := item.Price.Multiply(float64(item.Quantity))
        total, _ = total.Add(subtotal)
    }
    o.totalAmount = total
}

Aturan penting Aggregate:

• Akses OrderItem tidak boleh langsung dari luar — harus lewat Order
• Setiap operasi yang mengubah state harus melalui Aggregate Root
• Aggregate Root yang menjaga konsistensi — total selalu akurat, status selalu valid

Kalau kita akses OrderItem langsung dan ubah quantity-nya dari luar, siapa yang akan recalculate total? Tidak ada. Itu mengapa pintu masuknya harus satu.

6. Repository — Abstraksi Akses Data

Repository adalah abstraksi untuk akses data. Use Case tidak perlu tahu apakah data ada di PostgreSQL, Redis, atau bahkan API eksternal.

// Interface di domain layer — ini yang Use Case kenal
type OrderRepository interface {
    Save(order *Order) error
    FindByID(id OrderID) (*Order, error)
    FindByCustomer(customerID CustomerID, status *OrderStatus) ([]*Order, error)
    Delete(id OrderID) error
}

// Implementasi di infrastructure layer — Use Case tidak perlu tahu ini ada
type PostgresOrderRepository struct {
    db *sql.DB
}

func (r *PostgresOrderRepository) Save(order *Order) error {
    tx, err := r.db.Begin()
    if err != nil {
        return err
    }
    defer tx.Rollback()

    // Simpan header order
    _, err = tx.Exec(
        `INSERT INTO orders (id, customer_id, status, total_amount, created_at)
         VALUES ($1, $2, $3, $4, $5)
         ON CONFLICT (id) DO UPDATE SET status=$3, total_amount=$4`,
        order.ID(), order.CustomerID(), order.Status(), order.TotalAmount(), order.CreatedAt(),
    )
    if err != nil {
        return err
    }

    // Simpan items — hapus dulu yang lama
    _, err = tx.Exec(`DELETE FROM order_items WHERE order_id = $1`, order.ID())
    if err != nil {
        return err
    }

    for _, item := range order.Items() {
        _, err = tx.Exec(
            `INSERT INTO order_items (order_id, product_id, name, price, quantity) VALUES ($1, $2, $3, $4, $5)`,
            order.ID(), item.ProductID, item.Name, item.Price.Amount, item.Quantity,
        )
        if err != nil {
            return err
        }
    }

    return tx.Commit()
}

7. Domain Service — Ketika Logic Tidak Masuk ke Entity Mana Pun

Kadang ada operasi bisnis yang melibatkan beberapa Entity sekaligus dan tidak cocok masuk ke salah satunya. Di sinilah Domain Service dipakai.

// Transfer dana melibatkan dua Account — tidak cocok masuk ke salah satu
type FundTransferService struct {
    accountRepo AccountRepository
    eventBus    EventBus
}

func (s *FundTransferService) Transfer(fromID, toID AccountID, amount Money) error {
    from, err := s.accountRepo.FindByID(fromID)
    if err != nil {
        return err
    }

    to, err := s.accountRepo.FindByID(toID)
    if err != nil {
        return err
    }

    if err := from.Debit(amount); err != nil {
        return err  // saldo tidak cukup, dll
    }

    to.Credit(amount)
    if err := s.accountRepo.Save(from); err != nil {
        return err
    }

    if err := s.accountRepo.Save(to); err != nil {
        return err
    }

    s.eventBus.Publish(FundsTransferred{
        FromAccountID: fromID,
        ToAccountID:   toID,
        Amount:        amount,
        TransferredAt: time.Now(),
    })

    return nil
}

8. Domain Events — Sesuatu yang Telah Terjadi

Domain Events merepresentasikan sesuatu yang sudah terjadi di domain. Namanya selalu past tense: OrderPlaced, PaymentConfirmed, ItemShipped.

Ini berguna banget untuk integrasi antar Bounded Context tanpa coupling langsung. Context A publish event, Context B (dan C, D) bisa react tanpa A perlu tahu mereka ada.

// Event definition
type OrderConfirmed struct {
    OrderID     OrderID
    CustomerID  CustomerID
    TotalAmount Money
    Items       []OrderItem
    OccurredAt  time.Time
}

// Setelah order dikonfirmasi, publish event
func (o *Order) Confirm() error {
    if o.status != StatusDraft {
        return errors.New("only draft orders can be confirmed")
    }
    o.status = StatusConfirmed

    // Tambahkan ke list events yang belum di-dispatch
    o.events = append(o.events, OrderConfirmed{
        OrderID:     o.id,
        CustomerID:  o.customerID,
        TotalAmount: o.totalAmount,
        Items:       o.items,
        OccurredAt:  time.Now(),
    })

    return nil
}

// Bounded Context lain bisa listen ke event ini:
// - Inventori: kurangi stok
// - Notifikasi: kirim email konfirmasi ke customer
// - Analitik: catat untuk laporan penjualan
// Semua tanpa Order tahu mereka ada

Strategic vs Tactical DDD

DDD punya dua level yang perlu dipahami:

Banyak developer langsung loncat ke tactical (Entity, Aggregate, dsb) tanpa memikirkan strategic. Hasilnya: kode sudah pakai istilah DDD tapi sistemnya masih berantakan karena batas antar konteks tidak jelas.

Mulai dari strategic dulu. Definisikan Bounded Context, sepakati Ubiquitous Language dengan bisnis, baru kemudian implementasi tactical di masing-masing konteks.

DDD + Clean Architecture

DDD dan Clean Architecture adalah kombinasi yang sangat pas:

Clean Architecture Layer         DDD Concept
─────────────────────────────────────────────────────────
Entities                     →    Domain Layer
                                 (Entity, Value Object, Aggregate, Domain Events)

Use Cases                    →    Application Layer
                                 (orchestrate domain objects, call repositories)

Interface Adapters           →    Adapter Layer
                                 (controller, presenter, DTO mapping)

Frameworks & Drivers         →    Infrastructure Layer
                                 (DB implementation, HTTP framework, message broker)

Domain layer di Clean Architecture adalah tempat semua tactical DDD patterns tinggal. Use Case layer mengatur alur kerja dengan memanggil domain objects dan repositories.

Contoh Lengkap: Order Management

Berikut gambaran besar bagaimana semua potongan ini bekerja bersama:

// 1. Domain Layer — murni business logic

// domain/order.go
type Order struct { /* ... */ }
func (o *Order) AddItem(product Product, qty int) error { /* ... */ }
func (o *Order) Confirm() error { /* ... */ }

// domain/repository.go
type OrderRepository interface {
    Save(order *Order) error
    FindByID(id OrderID) (*Order, error)
}

// 2. Application Layer — orchestrate domain

// usecase/confirm_order.go
type ConfirmOrderUseCase struct {
    orderRepo OrderRepository
    eventBus  EventBus
}

func (uc *ConfirmOrderUseCase) Execute(orderID OrderID) error {
    order, err := uc.orderRepo.FindByID(orderID)
    if err != nil {
        return err
    }

    if err := order.Confirm(); err != nil {
        return err
    }

    if err := uc.orderRepo.Save(order); err != nil {
        return err
    }

    // Publish domain events
    for _, event := range order.PopEvents() {
        uc.eventBus.Publish(event)
    }

    return nil
}

// 3. Infrastructure Layer — implementasi teknis

// infra/postgres_order_repo.go
type PostgresOrderRepository struct { db *sql.DB }
func (r *PostgresOrderRepository) Save(order *Order) error { /* SQL */ }
func (r *PostgresOrderRepository) FindByID(id OrderID) (*Order, error) { /* SQL */ }

// 4. Delivery Layer — HTTP handler

// delivery/order_handler.go
func (h *OrderHandler) Confirm(c *fiber.Ctx) error {
    orderID := OrderID(c.Params("id"))
    if err := h.confirmOrder.Execute(orderID); err != nil {
        return c.Status(400).JSON(fiber.Map{"error": err.Error()})
    }
    return c.Status(200).JSON(fiber.Map{"message": "order berhasil dikonfirmasi"})
}

Kapan Harus Pakai DDD?

Pakai DDD kalau:

• ✅ Domain bisnis kompleks dengan banyak aturan dan edge case
• ✅ Ada domain expert yang bisa diajak diskusi
• ✅ Team cukup besar dan perlu pembagian yang jelas
• ✅ Sistem yang akan terus berkembang jangka panjang

Jangan pakai DDD kalau:

• Aplikasi CRUD sederhana — Active Record pattern jauh lebih praktis
• Tidak ada domain expert atau domain masih sangat blur
• Deadline ketat dan scope masih berubah-ubah
• Team kecil (1–2 developer) yang perlu gerak cepat

Kesimpulan

DDD adalah cara berpikir, bukan framework atau library. Tidak perlu langsung implement semua tactical patterns sekaligus.

Kalau baru mulai, fokus dulu pada dua hal: Ubiquitous Language dan Bounded Context. Dua hal itu saja sudah mengubah kualitas komunikasi tim secara signifikan — dan pada akhirnya itu yang paling berdampak ke kualitas software yang kita bangun.

Di artikel berikutnya: Hexagonal Architecture (Ports & Adapters) — cara mengorganisasi kode yang membuat aplikasi mudah di-test dan tidak terkunci ke satu framework atau database.

Pernah masuk ke project yang sudah berjalan 2 tahun, lalu diminta nambahin satu fitur kecil — tapi ujungnya 5 file lain ikut rusak? Atau mau ganti library, tapi ternyata logic bisnis nyangkut di mana-mana sampai susah dipisah?

Kalau iya, bukan berarti developernya yang salah. Itu tanda bahwa arsitektur aplikasinya bermasalah.

Artikel ini membahas Clean Architecture — pendekatan yang membantu kita membangun sistem yang mudah di-maintain, mudah di-test, dan tidak jadi beban di masa depan.

Apa Itu Clean Architecture?

Clean Architecture adalah konsep yang dipopulerkan oleh Robert C. Martin (Uncle Bob) melalui bukunya Clean Architecture: A Craftsman’s Guide to Software Structure and Design (2017). Tapi ide dasarnya sudah ada jauh sebelum itu.

Intinya sederhana: pisahkan kode berdasarkan tanggung jawabnya, dan pastikan dependensi hanya mengalir satu arah — ke dalam.

Visualisasinya berbentuk lingkaran konsentris:

┌──────────────────────────────────────┐
│       Frameworks & Drivers           │  ← HTTP, DB, Queue, dsb
│   ┌──────────────────────────────┐   │
│   │     Interface Adapters       │   │  ← Controller, Presenter
│   │   ┌──────────────────────┐   │   │
│   │   │      Use Cases       │   │   │  ← Application logic
│   │   │  ┌────────────────┐  │   │   │
│   │   │  │    Entities    │  │   │   │  ← Core domain
│   │   │  └────────────────┘  │   │   │
│   │   └──────────────────────┘   │   │
│   └──────────────────────────────┘   │
└──────────────────────────────────────┘

Semakin ke dalam, semakin stabil dan tidak bergantung pada hal-hal teknis. Entities tidak tahu soal database. Use cases tidak tahu soal HTTP. Dan itu yang membuat kode jadi fleksibel.

4 Layer Utama

1. Entities — Inti Bisnis

Entities adalah representasi dari aturan bisnis yang paling murni. Tidak ada import database, tidak ada HTTP, tidak ada framework. Ini adalah kode yang paling jarang berubah.

// Contoh di Go — Order sebagai Entity
type Order struct {
    ID         string
    CustomerID string
    Items       []OrderItem
    Status      OrderStatus
    TotalAmount float64
}

// Business rule langsung di Entity
func (o *Order) CanBeCancelled() bool {
    return o.Status == StatusPending || o.Status == StatusProcessing
}

func (o *Order) Cancel() error {
    if !o.CanBeCancelled() {
        return errors.New("order tidak bisa dibatalkan pada status ini")
    }
    o.Status = StatusCancelled
    return nil
}

Kalau ada perubahan aturan bisnis — misalnya “order yang sudah dikirim pun bisa dibatalkan dalam 1 jam” — kita hanya perlu ubah di sini.

2. Use Cases — Alur Bisnis

Use Cases mengatur bagaimana bisnis bekerja. Di sinilah alur seperti “buat order baru”, “batalkan order”, atau “proses pembayaran” ditulis. Use Case tahu tentang Entity, tapi tidak tahu soal database atau HTTP.

type CreateOrderUseCase struct {
    orderRepo  OrderRepository  // interface, bukan implementasi konkret
    notifier   Notifier
    stockChecker StockChecker
}

func (uc *CreateOrderUseCase) Execute(input CreateOrderInput) (*Order, error) {
    // 1. Validasi stok dulu
    for _, item := range input.Items {
        if !uc.stockChecker.IsAvailable(item.ProductID, item.Quantity) {
            return nil, ErrStockNotAvailable
        }
    }

    // 2. Buat order
    order := NewOrder(input.CustomerID, input.Items)

    // 3. Simpan
    if err := uc.orderRepo.Save(order); err != nil {
        return nil, err
    }

    // 4. Kirim notifikasi
    uc.notifier.Send(order.CustomerID, "Order berhasil dibuat: "+order.ID)
        return order, nil
    }

Perhatikan — tidak ada sql.DB, tidak ada fiber.Ctx, tidak ada http.Request. Murni logika bisnis.

3. Interface Adapters — Jembatan

Layer ini bertugas sebagai penerjemah. Controller menerima HTTP request, mengekstrak data yang dibutuhkan, lalu memanggil use case. Presenter mengonversi output use case ke format response yang sesuai.

// Controller di layer ini
type OrderHandler struct {
    createOrder *CreateOrderUseCase
}

func (h *OrderHandler) Create(c *fiber.Ctx) error {
    var req CreateOrderRequest
    if err := c.BodyParser(&req); err != nil {
        return c.Status(400).JSON(fiber.Map{"error": "request tidak valid"})
    }

    order, err := h.createOrder.Execute(CreateOrderInput{
        CustomerID: req.CustomerID,
        Items:       req.Items,
    })
    
    if err != nil {
        return c.Status(500).JSON(fiber.Map{"error": err.Error()})
    }

    return c.Status(201).JSON(order)
}

4. Frameworks & Drivers — Detail Teknis

Database, HTTP framework, message broker, third-party API — semua ada di sini. Layer ini boleh bergantung ke layer dalam, tapi layer dalam tidak boleh tahu tentang layer ini.

// Implementasi Repository di layer paling luar
type PostgresOrderRepository struct {
    db *sql.DB
}

func (r *PostgresOrderRepository) Save(order *Order) error {
    _, err := r.db.Exec(
        `INSERT INTO orders (id, customer_id, status, total_amount) VALUES ($1, $2, $3, $4)`,
        order.ID, order.CustomerID, order.Status, order.TotalAmount,
    )
    return err
}

Kalau suatu hari mau ganti PostgreSQL ke MongoDB — cukup buat implementasi baru dari OrderRepository interface. Use Case tidak perlu disentuh sama sekali.

The Dependency Rule — Aturan Paling Penting

Semua dependensi source code hanya boleh mengarah ke dalam.

Layer luar boleh bergantung ke layer dalam. Layer dalam tidak boleh tahu tentang layer luar. Ini bukan sekedar rekomendasi — ini adalah aturan yang tidak boleh dilanggar.

Implikasinya:

• Use Case tidak boleh import package database
• Entity tidak boleh tahu tentang HTTP request
• Business logic tidak boleh bergantung pada framework

Cara menjaga aturan ini: gunakan interface. Use Case bergantung pada OrderRepository (interface), bukan PostgresOrderRepository (implementasi). Interface tinggal di layer Use Case, implementasinya di layer luar.

Prinsip-Prinsip Pendukung

Clean Architecture tidak berdiri sendiri. Ada beberapa prinsip yang menjadi fondasinya dan perlu dipahami.

SOLID Principles

S — Single Responsibility Principle

Satu class, satu alasan untuk berubah. Kalau ada class yang mengurus validasi, kirim email, dan simpan ke database sekaligus — itu tanda bahwa class tersebut punya terlalu banyak tanggung jawab.

// ❌ Terlalu banyak tanggung jawab
type UserService struct{}
func (s *UserService) Register(data UserData) (*User, error) {
    // validasi input
    // simpan ke database
    // kirim welcome email
    // log aktivitas
    // return user
}

// ✅ Pisah berdasarkan tanggung jawab
type UserValidator struct{}
type UserRepository struct{}
type EmailService struct{}
type ActivityLogger struct{}

O — Open/Closed Principle

Terbuka untuk ekstensi, tertutup untuk modifikasi. Kalau mau tambah fitur baru, tambahkan kode baru — jangan ubah kode yang sudah ada dan sudah berjalan.

L — Liskov Substitution Principle

Subtype harus bisa menggantikan parent-nya tanpa merusak program. Ini penting banget saat bekerja dengan interface — implementasi baru harus berperilaku seperti yang diharapkan.

I — Interface Segregation Principle

Jangan paksa client bergantung pada method yang tidak mereka butuhkan.

// ❌ Interface terlalu gemuk
type UserRepository interface {
    Save(user User) error
    FindByID(id string) (*User, error)
    Delete(id string) error
    ExportToExcel() []byte      // tidak semua butuh ini
    GenerateReport() []byte     // tidak semua butuh ini
}

// ✅ Pisah interface sesuai kebutuhan
type UserWriter interface {
    Save(user User) error
    Delete(id string) error
}

type UserReader interface {
    FindByID(id string) (*User, error)
}

type UserExporter interface {
    ExportToExcel() []byte
}

D — Dependency Inversion Principle

Depend on abstraction, not concretion. Ini yang membuat Clean Architecture bisa bekerja — Use Case bergantung pada interface, bukan implementasi konkret.

// Use Case bergantung pada interface
type CheckoutUseCase struct {
    orderRepo    OrderRepository    // interface
    paymentGW    PaymentGateway     // interface
    emailSender  EmailSender        // interface
}

// Implementasi konkretnya di-inject dari luar (Dependency Injection)

Separation of Concerns

Setiap bagian kode harus fokus pada satu hal. Jangan campur query database dengan validasi input di tempat yang sama. Jangan taruh business logic di dalam controller.

DRY — Don’t Repeat Yourself

Duplikasi kode bukan cuma masalah estetika — ini masalah konsistensi. Kalau ada logic yang sama di dua tempat dan perlu diubah, salah satunya pasti kelewat. Representasikan setiap pengetahuan di satu tempat saja.

YAGNI — You Aren’t Gonna Need It

Jangan bangun fitur atau abstraksi “untuk jaga-jaga nanti”. Ini salah satu penyebab over-engineering. Bangun apa yang dibutuhkan sekarang, refactor kalau memang perlu.

Kenapa Ini Penting dalam Praktik?

Berikut perbandingan konkret yang sering terjadi:

| Situasi | Tanpa Clean Architecture | Dengan Clean Architecture |
|---|---|---|
| Ganti database | Refactor besar, nyentuh banyak file | Ganti 1 file implementasi repository |
| Unit test | Butuh database nyata, lambat | Mock interface, test jalan offline |
| Onboarding developer baru | Bingung karena logic nyebar | Struktur folder mencerminkan domain |
| Bug di satu fitur | Bisa merembet ke fitur lain | Perubahan terisolasi per layer |
| Tambah payment gateway baru | Ubah banyak tempat | Tambah 1 implementasi interface baru |

Struktur Folder di Go

Berikut contoh struktur yang umum dipakai untuk Clean Architecture di Go:

/internal
├── /domain
│   ├── order.go          ← Entity + business rules
│   ├── repository.go     ← Interface definitions
│   └── errors.go
├── /usecase
│   ├── create_order.go   ← Use case logic
│   ├── cancel_order.go
│   └── get_order.go
├── /delivery
│   └── /http
│       ├── handler.go    ← HTTP handlers
│       └── middleware.go
└── /repository
    └── /postgres
        └── order_repo.go ← Implementasi konkret

Dan di main.go, semua di-wire bersama:

func main() {
    db := connectDB()

    // Infrastructure
    orderRepo := postgres.NewOrderRepository(db)
    emailSender := smtp.NewEmailSender()

    // Use cases
    createOrder := usecase.NewCreateOrderUseCase(orderRepo, emailSender)
    cancelOrder := usecase.NewCancelOrderUseCase(orderRepo)

    // Delivery
    handler := http.NewOrderHandler(createOrder, cancelOrder)

    app := fiber.New()
    app.Post("/orders", handler.Create)
    app.Delete("/orders/:id", handler.Cancel)
    app.Listen(":3000")
}

Perhatikan: arah dependensi hanya ke dalam. handler tahu tentang usecase, usecase tahu tentang domain, tapi tidak ada yang jalan sebaliknya.

Kapan Harus Pakai Clean Architecture?

Clean Architecture bukan silver bullet. Ada overhead yang nyata — lebih banyak file, lebih banyak abstraksi, kurva belajar lebih tinggi.

Cocok dipakai kalau:

• ✅ Business logic cukup kompleks dan akan terus berkembang
• ✅ Team lebih dari 2–3 orang
• ✅ Project jangka panjang yang butuh maintainability tinggi
• ✅ Perlu unit testing yang serius

Mungkin overkill kalau:

• Project CRUD sederhana tanpa business logic yang kompleks
• MVP atau prototype yang butuh speed
• Script internal atau tooling satu kali pakai

Untuk project kecil, layered architecture biasa (Controller → Service → Repository) sudah lebih dari cukup. Jangan over-engineer dari awal.

Kesimpulan

Clean Architecture bukan tentang mengikuti diagram lingkaran dengan kaku. Ini tentang memahami kenapa kode perlu dipisah — supaya mudah diubah, mudah di-test, dan tidak jadi warisan masalah untuk developer berikutnya.

Kuncinya ada di satu aturan: dependensi hanya boleh mengalir ke dalam. Selama aturan itu dijaga dengan interface dan dependency injection, kamu sudah di jalur yang benar.

Di artikel berikutnya kita akan masuk lebih dalam ke Domain-Driven Design (DDD) — cara berpikir yang melengkapi Clean Architecture untuk sistem dengan domain bisnis yang kompleks.

Kalau artikel ini membantu, jangan lupa tinggalkan clap dan share ke rekan developer lainnya. Ada pertanyaan atau pengalaman yang berbeda? Tulis di komentar.

Di tahun 2026, AI sudah bisa generate kode. Copilot, Claude, ChatGPT — tinggal describe kebutuhan, kode muncul dalam hitungan detik.

Lalu pertanyaan wajarnya: ngapain masih belajar bahasa pemrograman baru?

Jawabannya sederhana: AI yang bagus butuh engineer yang paham apa yang di-generate-nya. Dan salah satu bahasa yang paling worth it untuk dipahami secara mendalam di era ini adalah Go.

Bukan karena Go “lebih keren” dari Python atau Node. Tapi karena Go dirancang untuk masalah nyata yang AI tidak bisa selesaikan sendiri — sistem yang harus jalan 24/7, menangani jutaan request, dan tetap stabil saat disentuh puluhan engineer sekaligus.

Apa itu Go?

Go (atau Golang) adalah bahasa pemrograman open-source yang mulai dikembangkan di Google pada 2007 oleh Rob Pike, Ken Thompson, dan Robert Griesemer. Diumumkan ke publik pada 2009, dan versi stabil 1.0 baru dirilis pada 2012.

Latar belakang pembuatannya cukup jelas: engineer Google frustrasi. C++ terlalu lambat dikompilasi. Java terlalu verbose. Python terlalu lambat di runtime. Mereka butuh bahasa yang bisa melakukan ketiganya dengan baik — cepat dikompilasi, cepat dieksekusi, dan mudah ditulis.

Go lahir dari frustrasi itu.

Kenapa Go Masih Relevan di Era AI?

1. Go adalah bahasa infrastruktur

Docker ditulis dengan Go. Kubernetes ditulis dengan Go. Terraform ditulis dengan Go. Prometheus ditulis dengan Go.

Artinya, setiap kali tim kamu deploy aplikasi ke cloud, tool yang bekerja di balik layar hampir pasti ditulis dengan Go. Memahami Go berarti kamu bisa membaca, memodifikasi, dan berkontribusi ke ekosistem ini — sesuatu yang AI tidak bisa lakukan untuk kamu tanpa konteks yang dalam.

2. Concurrency — titik lemah AI code generation

Ini yang paling penting.

Go punya model concurrency yang unik: goroutine dan channel. Konsepnya sederhana di permukaan, tapi sangat mudah salah implementasi.

// Kode yang "kelihatan benar" tapi bisa race condition
var counter int

func increment() {
    counter++ // NOT safe untuk concurrent access
}

func main() {
    for i := 0; i < 1000; i++ {
        go increment()
    }
}

AI bisa generate kode seperti di atas. Dan kode itu salah — ada race condition yang tidak langsung kelihatan saat development, tapi meledak di production.

Tanpa paham goroutine, channel, mutex, dan context, kamu tidak akan bisa catch bug seperti ini. Dan ini terjadi terus di dunia nyata.

3. Go memaksa kamu jadi engineer yang lebih baik

Go tidak punya exception. Tidak ada try-catch. Error handling di Go eksplisit — setiap fungsi yang bisa gagal harus di-handle langsung.

file, err := os.Open("data.json")
if err != nil {
    return fmt.Errorf("gagal buka file: %w", err)
}
defer file.Close()

Ini terasa verbose di awal. Tapi kebiasaan ini membuat kamu berpikir tentang apa yang bisa salah di setiap langkah — skill yang justru makin krusial di era AI di mana kode di-generate cepat tapi error handling sering di-skip.

4. Performa yang tidak bisa dikompromikan

Go adalah compiled language. Hasilnya adalah binary yang langsung jalan di OS tanpa runtime dependency.

Perbandingan sederhana untuk API yang sama:

Untuk aplikasi consumer biasa, perbedaan ini mungkin tidak terasa. Tapi untuk sistem yang handle jutaan user — perbedaan ini menentukan biaya server yang harus dibayar setiap bulan.

5. Deployment yang simpel

Compile Go menghasilkan satu binary. Satu file. Tidak perlu install runtime. Tidak perlu manage dependency di server.

# Build binary untuk Linux
GOOS=linux GOARCH=amd64 go build -o app ./cmd/main.go

# Deploy ke server
scp app user@server:/opt/myapp/

Dibanding Node.js yang butuh node_modules, atau Python yang butuh virtualenv dan pip install — ini signifikan ketika kamu manage banyak service.

Go Digunakan untuk Apa?

Go paling cocok untuk:

• Backend Service & API — REST API, gRPC service, microservice yang butuh performa tinggi.
• CLI Tools — Banyak developer tools industri ditulis dengan Go karena binary-nya ringan dan bisa di-distribute tanpa dependency.
• DevOps & Infrastructure — Kubernetes operators, custom controller, monitoring tools.
• Network Programming — Proxy, load balancer, DNS server.

Go bukan pilihan terbaik untuk: machine learning (Python lebih unggul ekosistemnya), frontend (jelas bukan), atau scripting cepat yang sekali pakai.

Go vs Bahasa Lain

Go bukan pengganti Python untuk ML, dan bukan pengganti JavaScript untuk frontend. Go adalah pilihan yang tepat ketika kamu butuh performa, reliability, dan simplicity sekaligus — di layer backend dan infrastructure.

Apakah Go Sulit Dipelajari?

Tidak — tapi ada beberapa konsep yang butuh waktu untuk benar-benar dipahami:

• Pointer — Go menggunakan pointer, tapi jauh lebih aman dari C/C++. Ini konsep yang perlu dipahami, bukan dihafal.
• Error handling — Seperti yang sudah dibahas, Go tidak pakai exception. Butuh perubahan mindset tapi hasilnya kode yang lebih predictable.
• Goroutine & channel — Ini yang paling banyak menyebabkan bug bagi yang baru belajar Go. Tapi justru inilah yang membuat Go powerful.

Syntaxnya sendiri sangat bersih. Tidak ada class, tidak ada inheritance yang kompleks, tidak ada magic framework yang harus dipelajari dulu sebelum mulai.

package main

import "fmt"

func main() {
    fmt.Println("Hello, Go!")
}

Ini valid Go program. Tidak ada boilerplate, tidak ada konfigurasi — langsung jalan.

Go di Era AI: Posisi yang Tepat

AI bagus untuk generate boilerplate, scaffold CRUD, dan suggest solusi umum. Tapi ada hal yang masih butuh manusia dengan pemahaman mendalam:

• Mendeteksi race condition di concurrent code
• Merancang sistem yang fault-tolerant
• Optimasi performa yang specific ke use case
• Debugging production issue yang tidak reproducible di local
• Memutuskan trade-off arsitektur

Go — dengan filosofi simpel tapi powerful — adalah bahasa yang mendorong kamu untuk benar-benar memahami apa yang kamu tulis. Bukan sekadar generate dan copy-paste.

Di era di mana semua orang bisa generate kode dengan AI, engineer yang paham apa yang di-generate-nya adalah yang paling dicari.

Kesimpulan

Go bukan hype. Go sudah dipakai di production oleh Google, Uber, Dropbox, Cloudflare, dan ratusan perusahaan lain selama lebih dari 10 tahun.

Di era AI, Go justru makin relevan — bukan karena melawan AI, tapi karena memberikan fondasi yang kuat untuk memahami sistem yang benar-benar berjalan di skala besar. Dan itulah yang membedakan engineer yang bisa menggunakan AI secara efektif dengan yang sekadar mengandalkannya.

Dalam pengembangan aplikasi Laravel, kita sering kali perlu menerapkan Policy untuk mengontrol akses pengguna berdasarkan izin (permission). Dalam artikel ini, kita akan membahas bagaimana cara mengimplementasikan Policy di Laravel tanpa library external.

Step-by-Step

Step 1: Buat Policy Baru

Kita perlu membuat sebuah policy yang akan digunakan untuk mengecek izin user terhadap resource tertentu. Misalnya, kita ingin membuat TaskPolicy untuk mengatur akses ke resource Task.

Jalankan perintah berikut:

php artisan make:policy TaskPolicy --model=Task

Ini akan menghasilkan file TaskPolicy.php di dalam folder app/Policies.

Step 2: Definisikan Policy

Buka file TaskPolicy.php dan tambahkan method untuk mengecek izin pengguna:

namespace App\Policies;

use App\Models\Task;
use App\Models\User;
use Illuminate\Auth\Access\HandlesAuthorization;

class TaskPolicy
{
    use HandlesAuthorization;

    public function viewAny(User $user): bool
    {
        if (request()->is('api/*')) {
            return $user->can('view_task_mob');
        }
        return $user->can('view_task');
    }

    public function view(User $user, Task $task): bool
    {
        return $user->can('view_task_mob');
    }  

    public function create(User $user): bool
    {
        return $user->can('create_task_mob');
    }

    public function update(User $user, Task $task): bool
    {
        return $user->can('update_task_mob');
    }
    public function delete(User $user, Task $task): bool
    {
        return $user->can('delete_task_mob');
    }
    public function approve(User $user, Task $task): bool
    {
        return $user->can('approve_task_mob');
    }
}

Pada method viewAny, kita melakukan pengecekan apakah request berasal dari API (api/*), lalu mengatur izin sesuai dengan itu.

Step 3: Daftarkan Policy di AuthServiceProvider

Sekarang, kita perlu mendaftarkan policy ini di AuthServiceProvider.php agar Laravel mengenalinya.

Buka file app/Providers/AuthServiceProvider.php dan tambahkan mapping berikut:

namespace App\Providers;

use App\Models\Task;
use App\Policies\TaskPolicy;
use Illuminate\Foundation\Support\Providers\AuthServiceProvider as ServiceProvider;
use Illuminate\Support\Facades\Gate;
class AuthServiceProvider extends ServiceProvider
{
    protected $policies = [
        Task::class => TaskPolicy::class,
    ];
    public function boot()
    {
        $this->registerPolicies();
    }
}

Step 4: Gunakan Policy di Controller

Di dalam controller, kita bisa menggunakan method authorizeResource() di __construct atau method authorize() di function diluar resources, untuk memastikan user memiliki izin sebelum melakukan suatu aksi. Contoh implementasinya di TaskController.php:

namespace App\Http\Controllers\Api;

use App\Http\Controllers\Controller;
use App\Models\Task;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Gate;

class TaskController extends Controller
{
    public function __construct()
    {
        $this->authorizeResource(Task::class, 'task');
    }
    public function index()
    {
        return response()->json(['message' => 'Task list retrieved successfully']);
    }
    public function store(Request $request)
    {
        return response()->json(['message' => 'Task created successfully']);
    }
    public function update(Request $request, Task $task)
    {
        return response()->json(['message' => 'Task updated successfully']);
    }
    public function destroy(Task $task)
    {
        return response()->json(['message' => 'Task deleted successfully']);
    }
    public function approve(Task $task)
    {
        $this->authorize('approve', $task);
        return response()->json(['message' => 'Task approved successfully']);
    }
}

Dengan authorizeResource(), Laravel otomatis akan mengecek izin berdasarkan konvensi penamaan berikut:

• index → viewAny
• show → view
• store → create
• update → update
• destroy → delete

Pastikan method-method ini ada di dalam policy!

Kesimpulan

Dengan menerapkan Policy di Laravel tanpa menggunakan library external, kita bisa memastikan bahwa hanya user yang memiliki izin yang benar yang bisa mengakses resource tertentu.

PostgreSQL adalah salah satu database relasional open-source yang sangat populer karena keandalan dan fitur-fiturnya yang canggih. Dalam artikel ini, kita akan membahas langkah-langkah untuk menginstal dan mengkonfigurasi PostgreSQL di server Linux.

Step-by-Step Install & Konfigurasi PostgreSQL

Step 1: Install PostgreSQL

Sebelum menginstall PostgreSQL, kita perlu memperbarui daftar paket terlebih dahulu:

sudo apt update

Kemudian, install PostgreSQL beserta paket tambahannya:

sudo apt install postgresql postgresql-contrib -y

Setelah proses instalasi selesai, PostgreSQL akan otomatis berjalan di sistem kita.

Step 2: Cek Status PostgreSQL

Untuk memastikan PostgreSQL sudah aktif, jalankan perintah berikut:

sudo systemctl status postgresql

Jika PostgreSQL berjalan dengan baik, output-nya akan menampilkan status active (running).

Step 3: Masuk ke PostgreSQL dan Buat User & Database

PostgreSQL secara default menggunakan akun postgres sebagai administrator database. Kita bisa masuk ke dalam PostgreSQL dengan perintah:

sudo -u postgres psql

Setelah masuk ke dalam PostgreSQL, buat database dan user baru:

CREATE DATABASE mydatabase;
CREATE USER myuser WITH ENCRYPTED PASSWORD 'mypassword';
ALTER DATABASE mydatabase OWNER TO myuser;

Keluar dari PostgreSQL dengan mengetikkan:

\q

Step 4: Konfigurasi Akses di pg_hba.conf

Secara default, PostgreSQL hanya mengizinkan koneksi dari user lokal. Untuk mengubahnya, kita perlu mengedit file konfigurasi pg_hba.conf:

sudo nano /etc/postgresql/14/main/pg_hba.conf

Cari baris seperti ini:

host    all             all             127.0.0.1/32            md5

Ubah metode autentikasinya menjadi scram-sha-256 jika kita ingin menggunakan enkripsi yang lebih aman:

host    all             all             127.0.0.1/32            scram-sha-256
host    all             all             0.0.0.0/0               scram-sha-256

Simpan perubahan dengan CTRL + X, lalu tekan Y dan Enter.

Step 5: Konfigurasi PostgreSQL agar Bisa Diakses Secara Remote

Secara default, PostgreSQL hanya mendengarkan koneksi lokal. Untuk mengubahnya, kita perlu mengedit file postgresql.conf.

sudo nano /etc/postgresql/14/main/postgresql.conf

Cari baris berikut:

#listen_addresses = 'localhost'

Ubah menjadi:

listen_addresses = '*'

Simpan perubahan dan keluar.

Step 6: Restart PostgreSQL

Setelah mengedit konfigurasi, kita harus me-restart PostgreSQL agar perubahan diterapkan:

sudo systemctl restart postgresql

Step 7: Buka Akses Firewall (Opsional, jika firewall aktif)

Jika kita menggunakan ufw sebagai firewall, pastikan PostgreSQL bisa menerima koneksi dari IP tertentu atau semua IP:

sudo ufw allow 5432/tcp

Atau jika hanya ingin mengizinkan akses dari IP tertentu (misalnya 192.168.1.100):

sudo ufw allow from 192.168.1.100 to any port 5432

Step 7: Cek Koneksi ke Database

Untuk memastikan semuanya berjalan dengan baik, coba koneksi ke database menggunakan perintah berikut:

// in vm
psql -U myuser -d mydatabase -h localhost
// or via local
psql -U myuser -d mydatabase -h <IP_SERVER>

Jika berhasil, kita akan masuk ke dalam PostgreSQL CLI.

Step 8: Cek log error

Jika ada kendala, pastikan kita mengecek log dengan:

sudo journalctl -u postgresql --no-pager | tail -n 50

Kesimpulan

Kita telah berhasil menginstal dan mengkonfigurasi PostgreSQL di server Linux. Dengan database yang sudah siap, kita bisa mulai menggunakannya untuk berbagai aplikasi, termasuk integrasi dengan Laravel, Golang, atau teknologi lainnya.

Saat kita mengembangkan aplikasi dengan Golang, sering kali kita perlu menjalankannya di server agar bisa diakses oleh pengguna. Salah satu cara terbaik adalah menggunakan Virtual Private Server (VPS). Dengan VPS, kita bisa mengontrol sepenuhnya bagaimana aplikasi berjalan, mengatur database, dan mengoptimalkan performa.

Di artikel ini, kita akan membahas cara menginstal dan menjalankan project Golang di VPS secara bertahap.

Why? Kenapa Perlu Menjalankan Golang di VPS?

Ada beberapa alasan kenapa menjalankan Golang di VPS adalah pilihan yang baik:

• Kontrol penuh — Kita bisa mengatur sistem sesuai kebutuhan.
• Stabil dan scalable — Tidak tergantung pada layanan cloud pihak ketiga.
• Lebih cepat dan efisien — Golang terkenal dengan performanya yang ringan dan cepat.
• Bisa dijadikan production-ready — Dengan VPS, kita bisa menyiapkan aplikasi untuk produksi.

Step-by-Step Menjalankan Project Golang di VPS

Step 1: Akses VPS

Pertama, kita perlu masuk ke VPS menggunakan SSH:

ssh user@your-vps-ip

Jika menggunakan key:

ssh -i /path/to/private_key user@your-vps-ip

Step 2: Install Golang di VPS

Cek apakah Golang sudah terinstal:

go version

Jika belum, kita bisa menginstalnya dengan cara berikut:

Debian/Ubuntu

sudo apt update
sudo apt install -y golang

CentOS/Rocky Linux

sudo yum install -y golang

Jika ingin menginstal versi terbaru secara manual:

wget https://go.dev/dl/go1.21.4.linux-amd64.tar.gz
sudo tar -C /usr/local -xzf go1.21.4.linux-amd64.tar.gz
echo 'export PATH=$PATH:/usr/local/go/bin' >> ~/.bashrc
source ~/.bashrc
go version

Step 3: Clone dan Setup Project Golang

Jika proyek kita ada di GitHub atau GitLab, clone repositori:

git clone https://github.com/user/project.git
cd project

Step 4: Konfigurasi Database (Opsional)

Jika aplikasi menggunakan database seperti MySQL atau PostgreSQL, kita perlu menginstalnya terlebih dahulu:

Install MySQL

sudo apt install -y mysql-server
sudo systemctl start mysql
sudo mysql_secure_installation

Install PostgreSQL

sudo apt install -y postgresql postgresql-contrib
sudo systemctl start postgresql

Step 5: Konfigurasi Environment

Jika proyek kita menggunakan file .env, buat dan sesuaikan:

cp .env.example .env
nano .env

Step 6: Install Dependencies

go mod tidy

Step 7: Build dan Jalankan Project

Jika Ingin Langsung Menjalankan

go run main.go

Build dan Jalankan Binary

go build -o myapp
./myapp

Jika ada direktori dengan nama app, pastikan kita tidak menggunakan nama output app agar tidak terjadi konflik.

Step 8: Menjalankan Aplikasi di Background

Menggunakan nohup

nohup ./myapp > output.log 2>&1 &

Menggunakan screen

screen -S myapp
./myapp

(Tekan Ctrl + A + D untuk keluar dari screen)

Menggunakan tmux

tmux new -s myapp
./myapp

(Keluar dengan Ctrl + B, lalu D)

Step 9: Setup Systemd untuk Menjalankan Otomatis

Buat service file:

sudo nano /etc/systemd/system/myapp.service

Tambahkan konfigurasi berikut:

[Unit]
Description=My Go App
After=network.target

[Service]
User=root
WorkingDirectory=/home/user/project
ExecStart=/home/user/project/myapp
Restart=always

[Install]
WantedBy=multi-user.target

Reload systemd dan jalankan service:

sudo systemctl daemon-reload
sudo systemctl enable myapp
sudo systemctl start myapp
sudo systemctl status myapp

Step 10: Setup Reverse Proxy dengan Nginx (Opsional)

Jika kita ingin mengakses aplikasi melalui domain atau subdomain, kita bisa menggunakan Nginx sebagai reverse proxy.

Install Nginx

sudo apt install -y nginx

Konfigurasi Reverse Proxy

sudo nano /etc/nginx/sites-available/myapp

Tambahkan konfigurasi berikut:

server {
    listen 80;
    server_name yourdomain.com;

    location / {
        proxy_pass http://localhost:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Aktifkan konfigurasi dan restart Nginx:

sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/
sudo systemctl restart nginx

Kesimpulan

Menjalankan project Golang di VPS memberi kita fleksibilitas dan kontrol penuh atas aplikasi yang kita buat. Dengan mengikuti langkah-langkah di atas, kita bisa memastikan aplikasi berjalan dengan lancar di server, bahkan secara otomatis saat server restart. Jika ingin aplikasi bisa diakses dengan domain, kita bisa mengatur reverse proxy dengan Nginx.

Pendahuluan

Dalam pengembangan aplikasi Laravel, menjaga agar kode tetap rapi dan mudah dikelola adalah tantangan utama. Laravel Action hadir sebagai pendekatan modern untuk memisahkan logika bisnis dari controller, membuat kode lebih modular, reusable, dan mudah diuji.

Artikel ini akan membahas apa itu Laravel Action, bagaimana cara menggunakannya, dan mengapa kita harus mempertimbangkannya dalam project kita.

Apa Itu Laravel Action?

Laravel Action adalah sebuah kelas yang dirancang untuk menangani tugas atau logika bisnis tertentu dalam aplikasi. Alih-alih memasukkan semua logika ke dalam controller atau model, Action memungkinkan kita untuk memisahkannya ke dalam satu tempat yang berdedikasi.

Manfaat Laravel Action:

1. Keterbacaan yang Lebih Baik: Kode lebih bersih karena logika terpisah dari controller.
2. Reusable: Action dapat digunakan di berbagai tempat (controller, job, command).
3. Testable: Mudah diuji secara terpisah karena terisolasi dari komponen lain.

Implementasi Laravel Action

1. Membuat Action

Buat folder Actions di dalam direktori app/. Di dalamnya, buat file RegisterUser.php.

namespace App\Actions;

use App\Models\User;
use Illuminate\Support\Facades\Mail;

class RegisterUser
{
    public function execute(array $data)
    {
        // Logika registrasi
        $user = User::create($data);
        // Kirim email selamat datang
        Mail::to($user->email)->send(new WelcomeMail($user));
        return $user;
    }
}

2. Menggunakan Action di Controller

Kita dapat memanggil Action dalam controller untuk mengurangi beban kode di controller.

namespace App\Http\Controllers;

use App\Actions\RegisterUser;
use Illuminate\Http\Request;

class AuthController extends Controller
{
    public function register(Request $request, RegisterUser $action)
    {
        $data = $request->validate([
            'name' => 'required|string|max:255',
            'email' => 'required|email|unique:users',
            'password' => 'required|string|min:8',
        ]);
        $user = $action->execute($data);
        return response()->json(['user' => $user], 201);
    }
}

3. Pengujian Action

Karena Action adalah kelas mandiri, pengujian menjadi lebih mudah.

namespace Tests\Unit;

use App\Actions\RegisterUser;
use Tests\TestCase;

class RegisterUserTest extends TestCase
{
    public function test_it_creates_a_user()
    {
        $action = new RegisterUser();
        $user = $action->execute([
            'name' => 'John Doe',
            'email' => 'john@example.com',
            'password' => bcrypt('password'),
        ]);
        $this->assertDatabaseHas('users', [
            'email' => 'john@example.com',
        ]);
    }
}

Kesimpulan

Laravel Action adalah cara yang sederhana namun efektif untuk mengatur logika bisnis dalam aplikasi. Dengan memisahkan logika dari controller, kita dapat menjaga kode tetap rapi, modular, dan mudah diuji.

Apakah pernah merasa bahwa query database memenuhi controller kita? Jika iya, maka Repository Pattern adalah solusi terbaik. Dengan Repository, kita dapat memisahkan logika manipulasi data dari controller, membuat aplikasi lebih terorganisir dan mudah diuji.

Artikel ini akan menjelaskan apa itu Repository Pattern, bagaimana cara menggunakannya, dan mengapa ini penting untuk aplikasi skala besar.

Apa Itu Repository Pattern?

Repository Pattern adalah teknik untuk mengelola akses data dengan menciptakan lapisan abstraksi antara model dan logika bisnis. Ini membantu menjaga kode tetap bersih, mempermudah pengujian, dan memungkinkan fleksibilitas saat mengganti sumber data.

Manfaat Repository Pattern:

1. Kode yang Terorganisir: Controller menjadi lebih bersih.
2. Fleksibilitas: Mudah mengganti sumber data (misalnya, dari MySQL ke API eksternal).
3. Testable: Logika akses data dapat diuji secara independen.

Implementasi Repository Pattern

1. Membuat Repository

Buat folder Repositories di dalam direktori app/. Di dalamnya, buat file UserRepository.php.

namespace App\Repositories;

use App\Models\User;

class UserRepository
{
    public function create(array $data)
    {
        return User::create($data);
    }
    public function findByEmail(string $email)
    {
        return User::where('email', $email)->first();
    }
}

2. Menggunakan Repository di Controller

Inject repository ke dalam controller menggunakan dependency injection.

namespace App\Http\Controllers;

use App\Repositories\UserRepository;
use Illuminate\Http\Request;

class UserController extends Controller
{
    protected $userRepository;

    public function __construct(UserRepository $userRepository)
    {
        $this->userRepository = $userRepository;
    }

    public function store(Request $request)
    {
        $data = $request->validate([
            'name' => 'required|string|max:255',
            'email' => 'required|email|unique:users',
            'password' => 'required|string|min:8',
        ]);
        $user = $this->userRepository->create($data);
        return response()->json(['user' => $user], 201);
    }
}

3. Pengujian Repository

Karena Repository terpisah dari controller, kita dapat menguji logikanya secara mandiri.

namespace Tests\Unit;

use App\Repositories\UserRepository;
use Tests\TestCase;

class UserRepositoryTest extends TestCase
{
    public function test_it_creates_a_user()
    {
        $repository = new UserRepository();

        $user = $repository->create([
            'name' => 'Jane Doe',
            'email' => 'jane@example.com',
            'password' => bcrypt('password'),
        ]);

        $this->assertDatabaseHas('users', [
            'email' => 'jane@example.com',
        ]);
    }
}

Kesimpulan

Repository Pattern adalah cara yang efisien untuk mengelola akses data di aplikasi Laravel. Dengan abstraksi ini, kita dapat menciptakan kode yang lebih bersih, fleksibel, dan mudah diuji.

Dalam pengembangan aplikasi berbasis backend, authentication adalah salah satu fitur yang hampir selalu dibutuhkan. Authentication memungkinkan kita untuk mengelola akses pengguna dengan aman, memastikan hanya user yang berhak yang bisa mengakses data tertentu.

Di artikel ini, kita akan membangun sistem authentication menggunakan Golang, Fiber (sebagai web framework), GORM (ORM untuk database), dan JWT (untuk authentication token). Kita juga akan menerapkan struktur folder yang terorganisir, mirip dengan Laravel, agar lebih modular dan scalable.

Why use Fiber & GORM?

1. Fiber adalah web framework yang ringan, cepat, dan memiliki sintaks yang mirip dengan Express.js, sehingga mudah digunakan.
2. GORM adalah ORM yang powerful untuk Golang, memungkinkan kita untuk berinteraksi dengan database secara lebih mudah.
3. JWT (JSON Web Token) digunakan untuk authentication, memungkinkan user mendapatkan token setelah login dan menggunakannya untuk mengakses endpoint yang dilindungi.
4. Struktur mirip Laravel membuat kode lebih rapi, terorganisir, dan mudah untuk dikembangkan.

Step by Step

1. Persiapan & Instalasi

Buat folder proyek baru dan jalankan perintah berikut:

mkdir go-auth && cd go-auth

Inisialisasi Go module:

go mod init go-auth

Install dependency yang diperlukan:

go get github.com/gofiber/fiber/v2
go get gorm.io/gorm
go get gorm.io/driver/mysql
go get github.com/golang-jwt/jwt/v5
go get github.com/joho/godotenv
go get golang.org/x/crypto/bcrypt

2. Struktur Folder

Kita akan menggunakan struktur folder berikut agar lebih modular:

/go-auth
├── /app
│   ├── /controllers
│   ├── /models
│   ├── /middleware
│   ├── /services
├── /bootstrap
├── /config
├── /routes
├── /utils
├── .env
├── go.mod
├── main.go

3. Konfigurasi Database

Buat file .env untuk menyimpan konfigurasi database dan JWT secret:

DB_USERNAME=root
DB_PASSWORD=password
DB_HOST=localhost
DB_PORT=3306
DB_NAME=golang_auth
JWT_SECRET=secret_key

Buat file config/database.go:

package config

import (
	"fmt"
	"log"
	"os"
	"github.com/joho/godotenv"
	"gorm.io/driver/mysql"
	"gorm.io/gorm"
)

var DB *gorm.DB

func ConnectDatabase() {
    godotenv.Load()

    dsn := fmt.Sprintf("%s:%s@tcp(%s:%s)/%s?charset=utf8mb4&parseTime=True&loc=Local",
          os.Getenv("DB_USERNAME"), os.Getenv("DB_PASSWORD"), os.Getenv("DB_HOST"), os.Getenv("DB_PORT"), os.Getenv("DB_NAME"))

    db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})
    if err != nil {
        log.Fatal("Failed to connect to database")
    }

    DB = db
    log.Println("Database connected!")
}

4. Konfigurasi Server

Buat file bootstrap/server.go :

package bootstrap

import (
     "github.com/gofiber/fiber/v2"
     "go-auth/routes"
     "log"
)

func StartServer() {
     app := fiber.New()
     routes.ApiRoutes(app)
     log.Println("Server running on port 8080")
     app.Listen(":8080")
}

5. Model User

Buat file app/models/user.go:

package models

import "gorm.io/gorm"

type User struct {
	gorm.Model
	Username string `gorm:"unique" json:"username"`
	Password string `json:"password"`
}

6. Utility untuk Hash Password dan JWT

Buat file utils/hash.go:

package utils

import "golang.org/x/crypto/bcrypt"

func HashPassword(password string) (string, error) {
	return bcrypt.GenerateFromPassword([]byte(password), bcrypt.DefaultCost)
}

func CheckPassword(hashedPassword, password string) error {
	return bcrypt.CompareHashAndPassword([]byte(hashedPassword), []byte(password))
}

Buat file utils/jwt.go:

package utils

import (
	"os"
	"time"
	"github.com/golang-jwt/jwt/v5"
)

var JwtKey = []byte(os.Getenv("JWT_SECRET"))

type Claims struct {
	Username string `json:"username"`
	jwt.RegisteredClaims
}

func GenerateToken(username string) (string, error) {
	expirationTime := time.Now().Add(24 * time.Hour)
	claims := &Claims{
		Username: username,
		RegisteredClaims: jwt.RegisteredClaims{
			ExpiresAt: jwt.NewNumericDate(expirationTime),
		},
	}
	token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
	return token.SignedString(JwtKey)
}

7. Authentication Controller

Buat file app/controllers/auth_controller.go:

package controllers

import (
	"github.com/gofiber/fiber/v2"
	"go-auth/services"
)

func RegisterHandler(c *fiber.Ctx) error {
	var data map[string]string
	if err := c.BodyParser(&data); err != nil {
		return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"message": "Invalid request"})
	}
	err := services.RegisterUser(data["username"], data["password"])
	if err != nil {
		return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"message": "Failed to create user"})
	}

        return c.Status(fiber.StatusCreated).JSON(fiber.Map{"message": "User registered successfully"})
}

8. Routing

Buat file routes/api.go:

package routes

import (
	"github.com/gofiber/fiber/v2"
	"go-auth/controllers"
)

func ApiRoutes(app *fiber.App) {
	v1 := app.Group("/v1")

       auth := v1.Group("/auth")
       auth.Post("/register", controllers.RegisterHandler)
       auth.Post("/login", controllers.LoginHandler)

       home := v1.Group("/home", middleware.AuthMiddleware)
       home.Get("/", func(c *fiber.Ctx) error {
          return c.JSON(fiber.Map{"message": "Hello World!"})
       })
}

9. Menjalankan Server

Buat file main.go:

package main

import (
	"go-auth/bootstrap"
	"go-auth/config"
)

func main() {
	config.ConnectDatabase()
        config.DB.AutoMigrate(&models.User{})
	bootstrap.StartServer()
}

Jalankan server dengan:

go run main.go

10. Testing API dengan Postman

Untuk menguji endpoint yang telah dibuat, kita bisa menggunakan Postman:

1. Register User

• Method: POST
• URL: http://127.0.0.1:8080/v1/auth/register
• Body (JSON):

{   
  "username": "superadmin",   
  "password": "password" 
}

2. Login User

• Method: POST
• URL: http://127.0.0.1:8080/v1/auth/login
• Body (JSON):

{   
  "username": "superadmin",   
  "password": "password" 
}

Response akan berisi token JWT.

3. Akses Endpoint Terproteksi

• Method: GET
• URL: http://localhost:3000/v1/home
• Headers:
  - Authorization: Bearer <JWT_TOKEN>
• Result:

{
    "message": "Hello World!"
}

Kesimpulan

Dengan struktur ini, kita telah berhasil membangun API authentication dengan Golang, Fiber, dan GORM. API ini sudah mendukung register, login, serta proteksi endpoint dengan JWT. Dengan struktur yang modular seperti Laravel, proyek ini bisa dikembangkan lebih lanjut dengan mudah.

GitHub - jeriatno/go-auth: Simple Golang Authentication API with Fiber & GORM

Expo Application Services (EAS) merupakan solusi yang mempermudah proses build dan deploy aplikasi React Native. Dalam artikel ini, kita akan membahas langkah-langkah menginstall dan melakukan build project React Native menggunakan EAS.

Instalasi dan Konfigurasi

Step 1: Install Expo CLI dan EAS CLI

Jika belum terinstall, pastikan untuk menginstall Expo CLI dan EAS CLI terlebih dahulu:

pnpm install -g expo-cli eas-cli

Step 2: Login ke EAS

Sebelum menggunakan EAS, login terlebih dahulu menggunakan perintah berikut:

eas login

Masukkan kredensial akun Expo kita.

Step 3: Inisialisasi EAS di Proyek

Masuk ke direktori proyek React Native kita dan jalankan perintah berikut untuk menginisialisasi EAS:

eas init

Perintah ini akan menambahkan file eas.json di dalam proyek.

Step 4: Konfigurasi .env untuk API

Berdasarkan kode yang digunakan, tambahkan variabel berikut di .env:

EXPO_PUBLIC_API_URL=https://your-api-url.com

Pastikan konfigurasi ini di-load dengan expo-constants atau modul lain yang sesuai.

Proses Build dengan EAS

Step 1: Menjalankan Build Lokal

Jalankan perintah berikut untuk melakukan build lokal:

EAS_LOCAL_BUILD_SKIP_CLEANUP=1 \
EAS_LOCAL_BUILD_ARTIFACTS_DIR=build \
RCT_NO_LAUNCH_PACKAGER=1 \
eas build --local --clear-cache --non-interactive --json --platform android --profile preview

Step 2: Menjalankan Build untuk Preview

Gunakan perintah berikut untuk build dengan profil preview di cloud:

eas build --platform android --profile preview

Step 3: Menjalankan Build untuk Produksi

Gunakan perintah berikut untuk build dengan profil production:

eas build --platform android --profile production

Cara Mengakses Aplikasi Setelah Build

Setelah proses build selesai, kita dapat mengakses aplikasi dengan cara berikut:

1. Menggunakan QR Code: Scan QR Code yang muncul di terminal atau EAS Dashboard menggunakan aplikasi Expo Go.
2. Menggunakan URL: Klik URL unduhan yang diberikan oleh EAS di terminal atau dashboard untuk menginstal aplikasi langsung di perangkat.
3. Menggunakan CLI: Jalankan perintah berikut untuk melihat hasil build dan mendapatkan tautan unduhan:

• eas build:list --platform android

Perintah ini akan menampilkan daftar build yang tersedia beserta QR code dan tautan unduhan.

Kesimpulan

Dengan mengikuti panduan ini, kita dapat menginstall dan melakukan build proyek React Native dengan EAS melalui device kita secara langsung tanpa menggunakan emulator.