Struct dan Method
Model Domain Backend

Go tidak punya class, tetapi tetap bisa memodelkan domain dengan rapi.

Kalau kamu datang dari TypeScript atau PHP, anggap struct sebagai wadah data yang eksplisit, lalu method sebagai perilaku yang ditempelkan ke tipe itu.

Di TypeScript kamu mungkin membuat interface Product untuk bentuk data dan class ProductService untuk perilaku. Di Laravel kamu sering bertemu Model Eloquent yang sekaligus membawa data, query, relasi, dan sebagian behavior. Go memisahkan hal ini lebih tegas: struct adalah bentuk data, method adalah perilaku pada tipe, sedangkan akses database nanti kita taruh di repository.

Modul ini melanjutkan langsung dari modul fungsi dan error. Di sana Order baru kita sketsa seminimal Order{ID, Total} karena fokusnya error return. Sekarang kita modelkan entitas inti dengan benar: User, Product, CartItem, Order, Payment, dan Inventory. Inilah bahasa dasar yang dipakai sepanjang roadmap, sebelum masuk ke Web API, PostgreSQL, clean architecture, dan transaksi checkout.

Acuan resmi yang relevan: Effective Go, Go Specification tentang Struct types dan Method sets, serta paket encoding/json.

Mirip interface TypeScript dari sisi bentuk, tetapi ia hidup sebagai tipe runtime Go.

Struct menjawab satu pertanyaan sederhana: field apa saja yang membentuk satu konsep domain?

Bandingkan cara kamu biasanya mendeskripsikan produk di TypeScript dengan cara Go.

product.tsSalin
export interface Product {
  id: number;
  sku: string;
  name: string;
  priceRupiah: number;
  quantity: number;
  status: "draft" | "active" | "archived" | "out_of_stock";
}

Versi Go meneruskan konvensi proyek dari modul tipe dan control flow: uang sebagai PriceRupiah int64 (bukan float, bukan tipe uang khusus), Quantity sebagai stok tersedia, dan Status bertipe ProductStatus.

internal/product/product.goSalin
package product

type ProductStatus string

const (
	ProductStatusDraft      ProductStatus = "draft"
	ProductStatusActive     ProductStatus = "active"
	ProductStatusArchived   ProductStatus = "archived"
	ProductStatusOutOfStock ProductStatus = "out_of_stock"
)

func (s ProductStatus) IsSellable() bool {
	return s == ProductStatusActive
}

type Product struct {
	ID          int64
	SKU         string
	Name        string
	Category    string
	PriceRupiah int64
	Quantity    int // stok tersedia
	Status      ProductStatus
}

Perhatikan huruf besar di awal nama field. Di Go, identifier yang diawali huruf besar diekspor dari package, sedangkan yang huruf kecil tidak. Karena Product nanti dibaca handler, service, dan repository di package berbeda, field-nya dibuat exported. Aturan ekspor ini kita perdalam di modul packages nanti.

Receiver membuat fungsi terasa seperti perilaku milik tipe, tanpa class.

Sintaks method Go adalah func (p Product) NamaMethod() tipe. Bagian p Product sebelum nama method itulah receiver-nya.

Method berikut menjawab pertanyaan domain: apakah produk boleh tampil di katalog, apakah produk bisa dibeli, dan bagaimana harga ditampilkan.

internal/product/behavior.goSalin
package product

import "fmt"

func (p Product) CanBeListed() bool {
	return p.Status == ProductStatusActive
}

func (p Product) CanBePurchased(qty int) bool {
	return p.Status == ProductStatusActive && p.Quantity >= qty
}

func (p Product) DisplayPrice() string {
	return fmt.Sprintf("Rp%d", p.PriceRupiah)
}

Dari sisi pemanggilan, method terasa mirip object method di JavaScript atau PHP: product.CanBePurchased(2).

internal/product/behavior_usage.goSalin
package product

func examplePurchase() bool {
	p := Product{
		ID:          1,
		SKU:         "SKN-SERUM-NIA-30",
		Name:        "Niacinamide Serum 30ml",
		PriceRupiah: 129000,
		Quantity:    25,
		Status:      ProductStatusActive,
	}

	return p.CanBePurchased(2)
}

Method tidak terbatas pada struct. Method bisa didefinisikan pada tipe bernama apa pun yang dideklarasikan di package-mu. Kamu sebenarnya sudah memakai ini sejak modul control flow: IsSellable adalah method pada ProductStatus, sebuah tipe berbasis string, bukan struct.

internal/product/product.goSalin
// ProductStatus adalah tipe string, tetapi tetap bisa punya method.
func (s ProductStatus) IsSellable() bool {
	return s == ProductStatusActive
}

classDiagram
  class ProductStatus {
    <<string>>
    +IsSellable() bool
  }
  class Product {
    +int64 ID
    +string Name
    +int64 PriceRupiah
    +int Quantity
    +ProductStatus Status
    +CanBePurchased(qty) bool
    +DisplayPrice() string
  }
  class CartItem {
    +Product Product
    +int Qty
    +LineTotal() int64
  }
  Product --> ProductStatus : Status
  CartItem --> Product : memuat

Gambar 1. Struct membawa data, method menempel sebagai perilaku milik tipe. ProductStatus membuktikan method tidak harus pada struct: tipe berbasis string pun boleh punya IsSellable.

Method bukan tempat akses database. product.CanBePurchased(2) boleh memeriksa state yang sudah ada di struct, tetapi query stok terbaru dari PostgreSQL nanti menjadi tanggung jawab repository atau service.

Pilihan receiver menentukan apakah method bekerja pada salinan atau nilai asli.

Value receiver menerima salinan dari nilai, pointer receiver menerima alamat nilai asli. Perbedaan ini menentukan apakah perubahan di dalam method ikut terlihat oleh pemanggil.

Contoh value receiver pada CartItem, karena method hanya menghitung dari data yang sudah ada. Di modul fungsi, LineTotal masih berupa fungsi bebas LineTotal(item). Sekarang kita jadikan ia method milik CartItem, sehingga terbaca sebagai item.LineTotal().

internal/checkout/cart.goSalin
package checkout

import "github.com/kamu/skincare-backend/internal/product"

type CartItem struct {
	Product product.Product
	Qty     int
}

// LineTotal kini menjadi method milik CartItem, bukan fungsi bebas.
// Value receiver sudah cukup karena ia hanya membaca.
func (item CartItem) LineTotal() int64 {
	return item.Product.PriceRupiah * int64(item.Qty)
}

Contoh pointer receiver pada Order, karena method mengubah status, payment id, dan waktu pembayaran. Inilah Order versi lengkap yang menggantikan sketsa minimal dari modul fungsi.

internal/order/order.goSalin
package order

import (
	"errors"
	"time"

	"github.com/kamu/skincare-backend/internal/checkout"
)

type OrderStatus string

const (
	OrderStatusPending   OrderStatus = "pending"
	OrderStatusPaid      OrderStatus = "paid"
	OrderStatusCancelled OrderStatus = "cancelled"
)

type Order struct {
	ID        int64
	UserID    int64
	Items     []checkout.CartItem
	Total     int64
	Status    OrderStatus
	PaymentID int64
	PaidAt    *time.Time
	CreatedAt time.Time
}

func (o *Order) MarkPaid(paymentID int64, paidAt time.Time) error {
	if o.Status != OrderStatusPending {
		return errors.New("order must be pending before it can be paid")
	}

	o.Status = OrderStatusPaid
	o.PaymentID = paymentID
	o.PaidAt = &paidAt
	return nil
}

Kalau MarkPaid memakai value receiver, perubahan status hanya terjadi pada salinan Order, lalu hilang begitu method selesai. Pemanggil tidak akan pernah melihat order menjadi paid.

internal/order/order_bug.goSalin
package order

import "time"

// MarkPaidWrong adalah versi salah: value receiver membuat semua mutasi
// hanya berlaku pada salinan, lalu dibuang saat method selesai.
func (o Order) MarkPaidWrong(paymentID int64, paidAt time.Time) {
	o.Status = OrderStatusPaid
	o.PaymentID = paymentID
	o.PaidAt = &paidAt
}

flowchart TD
  O["order asli, Status pending"] -->|"value receiver, struct disalin"| V["salinan o, Status jadi paid"]
  V -.->|"method selesai, salinan dibuang"| X["order asli TETAP pending"]
  O -->|"pointer receiver, kirim alamat"| P["o menunjuk order asli"]
  P -->|"o.Status = paid"| Y["order asli JADI paid"]

Gambar 2. Inti perbedaan receiver. Value receiver bekerja pada salinan yang dibuang, sedangkan pointer receiver bekerja pada alamat order asli sehingga mutasi benar-benar menempel.

Aturan praktisnya sederhana. Jika satu tipe punya satu saja method yang butuh pointer receiver, buat method lain pada tipe itu juga memakai pointer receiver agar method set-nya konsisten. Konsistensi ini penting saat tipe bertemu interface di modul nanti, karena method dengan pointer receiver hanya masuk method set *Order, bukan Order.

Terasa seperti extends, tetapi sebenarnya composition.

Go tidak punya inheritance. Untuk memakai ulang field atau behavior, Go memakai composition lewat embedded struct.

Di Laravel atau OOP PHP, kamu mungkin membuat BaseModel lalu model lain mewarisi field seperti timestamp. Di Go, pola idiomatiknya adalah menyusun (embed) tipe kecil ke dalam tipe lain.

internal/product/timestamps.goSalin
package product

import "time"

type Timestamps struct {
	CreatedAt time.Time
	UpdatedAt time.Time
}

func (t Timestamps) WasUpdated() bool {
	return t.UpdatedAt.After(t.CreatedAt)
}

Sekarang kita perbarui product.go agar Product meng-embed Timestamps. Embedded field ditulis tanpa nama field, hanya tipenya.

internal/product/product.goSalin
package product

type Product struct {
	Timestamps // embedded: field dan method-nya dipromosikan

	ID          int64
	SKU         string
	Name        string
	Category    string
	PriceRupiah int64
	Quantity    int
	Status      ProductStatus
}

Karena Timestamps di-embed, field CreatedAt dan UpdatedAt serta method WasUpdated dipromosikan ke Product. Kamu bisa menulis product.CreatedAt dan product.WasUpdated() langsung, seolah keduanya milik Product.

internal/product/audit_usage.goSalin
package product

func recentlyChanged(p Product) bool {
	// CreatedAt dan WasUpdated berasal dari Timestamps, tetapi dipanggil
	// langsung pada Product berkat field dan method promotion.
	return p.WasUpdated() && !p.CreatedAt.IsZero()
}

classDiagram
  class Timestamps {
    +time.Time CreatedAt
    +time.Time UpdatedAt
    +WasUpdated() bool
  }
  class Product {
    +int64 ID
    +string Name
    +int64 PriceRupiah
    +ProductStatus Status
  }
  Product *-- Timestamps : embed

Gambar 3. Embedded struct adalah komposisi, bukan pewarisan. Product tersusun dari Timestamps, lalu field dan method Timestamps dipromosikan agar nyaman diakses lewat Product.

Struct tag mengatur nama dan perilaku field saat menjadi JSON.

Frontend biasanya memakai snake_case atau camelCase, sedangkan field exported Go wajib diawali huruf besar. JSON tag adalah jembatannya.

Struct tag ditulis setelah tipe field, di dalam backtick. Paket encoding/json membaca key json, lalu memakai nama itu saat marshal dan unmarshal.

internal/httpapi/dto/order_response.goSalin
package dto

import "time"

type OrderResponse struct {
	ID        int64     `json:"id"`
	UserID    int64     `json:"user_id"`
	Total     int64     `json:"total"`
	Status    string    `json:"status"`
	PaymentID *int64    `json:"payment_id,omitempty"`
	PaidAt    time.Time `json:"paid_at,omitzero"`
	CreatedAt time.Time `json:"created_at"`
}

Perhatikan tiga keputusan penting pada tag di atas.

Untuk order yang belum dibayar, PaymentID masih nil dan PaidAt masih zero, sehingga keduanya tidak ikut dikirim.

response-belum-dibayar.jsonSalin
{
  "id": 1001,
  "user_id": 7,
  "total": 258000,
  "status": "pending",
  "created_at": "2026-06-06T10:00:00Z"
}

Setelah MarkPaid dipanggil, kedua field itu terisi dan ikut muncul.

response-sudah-dibayar.jsonSalin
{
  "id": 1001,
  "user_id": 7,
  "total": 258000,
  "status": "paid",
  "payment_id": 5001,
  "paid_at": "2026-06-06T10:03:00Z",
  "created_at": "2026-06-06T10:00:00Z"
}

DTO adalah kontrak keluar masuk API, domain model adalah pusat aturan bisnis.

Kesalahan umum backend pemula adalah memakai satu struct yang sama untuk request JSON, response JSON, database row, dan domain entity sekaligus.

DTO request menampung apa yang dikirim frontend. Bentuknya rata dan sederhana, hanya cukup untuk divalidasi lalu dipetakan ke domain.

internal/httpapi/dto/create_order.goSalin
package dto

type CreateOrderRequest struct {
	UserID int64             `json:"user_id"`
	Items  []CreateOrderItem `json:"items"`
}

type CreateOrderItem struct {
	ProductID int64 `json:"product_id"`
	Qty       int   `json:"qty"`
}

Domain model adalah order.Order dari bagian sebelumnya: ia membawa method dan aturan bisnis, bukan JSON tag. Yang menyatukan keduanya adalah fungsi mapping eksplisit dari domain ke DTO response.

internal/httpapi/dto/mapping.goSalin
package dto

import "github.com/kamu/skincare-backend/internal/order"

func NewOrderResponse(o order.Order) OrderResponse {
	resp := OrderResponse{
		ID:        o.ID,
		UserID:    o.UserID,
		Total:     o.Total,
		Status:    string(o.Status),
		CreatedAt: o.CreatedAt,
	}

	if o.PaymentID != 0 {
		paymentID := o.PaymentID
		resp.PaymentID = &paymentID
	}

	if o.PaidAt != nil {
		resp.PaidAt = *o.PaidAt
	}

	return resp
}

Mapping ini terlihat seperti kerja ekstra, tetapi justru di sinilah nilainya. Domain bebas berubah tanpa langsung merusak kontrak API, dan API bisa menyesuaikan bentuk untuk frontend tanpa mengotori aturan bisnis. OrderStatus yang bertipe string di domain pun dengan sengaja dipetakan menjadi string biasa di DTO.

flowchart LR
  FE["Frontend React"] -->|"JSON masuk"| REQ["CreateOrderRequest DTO"]
  REQ -->|"validasi dan mapping"| DOM["Order domain model"]
  DOM -->|"method: NewOrder, MarkPaid"| RULE["aturan bisnis"]
  DOM -->|"NewOrderResponse"| RES["OrderResponse DTO"]
  RES -->|"JSON keluar"| FE

Gambar 4. DTO menjaga kontrak HTTP di kedua ujung, domain model menjaga aturan bisnis di tengah. Dua fungsi mapping adalah pintu masuk dan pintu keluarnya.

Menyusun tipe inti yang dipakai sepanjang sisa roadmap.

Sekarang kita satukan semuanya menjadi enam entitas inti yang disebut Student Outcome roadmap: User, Product, CartItem, Order, Payment, dan Inventory.

Setiap entitas tinggal di package fiturnya sendiri, melanjutkan struktur yang sudah kita bentuk di modul fungsi dan error.

User memakai value receiver karena DisplayName hanya membaca.

internal/user/user.goSalin
package user

import "time"

type User struct {
	ID        int64
	Email     string
	FullName  string
	CreatedAt time.Time
}

func (u User) DisplayName() string {
	if u.FullName != "" {
		return u.FullName
	}

	return u.Email
}

Inventory memisahkan stok Available dari stok Reserved, dan memakai pointer receiver pada Reserve karena ia memutasi state.

internal/product/inventory.goSalin
package product

import "errors"

type Inventory struct {
	ProductID int64
	Available int
	Reserved  int
}

func (i Inventory) CanReserve(qty int) bool {
	return qty > 0 && i.Available >= qty
}

func (i *Inventory) Reserve(qty int) error {
	if !i.CanReserve(qty) {
		return errors.New("insufficient inventory to reserve")
	}

	i.Available -= qty
	i.Reserved += qty
	return nil
}

Payment mencatat hasil dari provider pembayaran, dengan nominal tetap dalam rupiah int64.

internal/payment/payment.goSalin
package payment

import "time"

type Payment struct {
	ID           int64
	OrderID      int64
	AmountRupiah int64
	Provider     string
	ReferenceNo  string
	PaidAt       time.Time
}

Karena Go tidak punya constructor, kita memakai fungsi pembuat seperti NewOrder untuk menjamin order lahir dalam keadaan valid. Pola ini meneruskan gaya (Data, error) dari modul fungsi dan memanggil item.LineTotal() yang kini sudah jadi method.

internal/order/factory.goSalin
package order

import (
	"errors"
	"time"

	"github.com/kamu/skincare-backend/internal/checkout"
)

func NewOrder(id, userID int64, items []checkout.CartItem, now time.Time) (Order, error) {
	if userID == 0 {
		return Order{}, errors.New("user id is required")
	}

	if len(items) == 0 {
		return Order{}, errors.New("order must contain at least one item")
	}

	var total int64
	for _, item := range items {
		if item.Qty <= 0 {
			return Order{}, errors.New("item quantity must be positive")
		}

		total += item.LineTotal()
	}

	return Order{
		ID:        id,
		UserID:    userID,
		Items:     items,
		Total:     total,
		Status:    OrderStatusPending,
		CreatedAt: now,
	}, nil
}

Keenam entitas saling terhubung membentuk peta domain online shop skincare.

erDiagram
  USER ||--o{ ORDER : "membuat"
  ORDER ||--|{ CART_ITEM : "berisi"
  CART_ITEM }o--|| PRODUCT : "merujuk"
  PRODUCT ||--o| INVENTORY : "punya stok"
  ORDER ||--o| PAYMENT : "dibayar oleh"

Gambar 5. Peta entitas inti. Satu user bisa punya banyak order, satu order berisi banyak cart item yang merujuk produk, tiap produk punya satu inventory, dan satu order dibayar oleh paling banyak satu payment.

Order sendiri bergerak melalui daur hidup status, dan MarkPaid adalah transisi terjaga dari pending ke paid.

stateDiagram-v2
  [*] --> Pending: NewOrder
  Pending --> Paid: MarkPaid
  Pending --> Cancelled: batalkan
  Paid --> [*]
  Cancelled --> [*]

Gambar 6. Daur hidup order. Method pointer receiver seperti MarkPaid menjaga agar transisi hanya terjadi dari status yang sah, persis seperti guard clause yang kamu pelajari di modul control flow.

Buat model domain kecil, jalankan test, lalu rasakan efek pointer receiver.

Latihan ini tidak butuh database. Kita hanya menguji perilaku struct dan method.

internal/checkout/cart_test.goSalin
package checkout

import (
	"testing"

	"github.com/kamu/skincare-backend/internal/product"
)

func TestCartItemLineTotal(t *testing.T) {
	item := CartItem{
		Product: product.Product{
			Name:        "Niacinamide Serum 30ml",
			PriceRupiah: 129000,
			Quantity:    25,
			Status:      product.ProductStatusActive,
		},
		Qty: 2,
	}

	got := item.LineTotal()
	want := int64(258000)

	if got != want {
		t.Fatalf("line total mismatch: got %d want %d", got, want)
	}
}

internal/order/order_test.goSalin
package order

import (
	"testing"
	"time"
)

func TestOrderMarkPaid(t *testing.T) {
	createdAt := time.Date(2026, 6, 6, 10, 0, 0, 0, time.UTC)
	paidAt := time.Date(2026, 6, 6, 10, 3, 0, 0, time.UTC)

	o := Order{
		ID:        1001,
		UserID:    7,
		Total:     258000,
		Status:    OrderStatusPending,
		CreatedAt: createdAt,
	}

	if err := o.MarkPaid(5001, paidAt); err != nil {
		t.Fatalf("mark paid failed: %v", err)
	}

	if o.Status != OrderStatusPaid {
		t.Fatalf("status mismatch: got %s want %s", o.Status, OrderStatusPaid)
	}

	if o.PaidAt == nil {
		t.Fatal("paid at should be set after MarkPaid")
	}
}

TerminalSalin
go test ./...

Sebagian bug Go pemula lahir dari membawa kebiasaan class dan object terlalu jauh.

Go terasa sederhana, tetapi beberapa aturan kecil sering mengejutkan developer JavaScript dan PHP.

Struct dan method adalah fondasi cara Go memodelkan domain backend tanpa class.

Pemetaan ke proyek online shop skincare