Repository Pattern dengan pgx
Akses Database yang Testable

Mengunci batas antara aturan bisnis dan SQL PostgreSQL

Di sembilan chapter Roadmap 3, kamu sudah menulis koneksi pgxpool, query baca, write dengan RETURNING, transaksi checkout, dan index. Sekarang semuanya dirapikan ke dalam satu lapis yang punya batas jelas: repository.

Repository pattern adalah cara mengisolasi detail penyimpanan data di balik sebuah interface. Handler menerima HTTP, service menjalankan aturan bisnis, repository berbicara dengan PostgreSQL lewat pgx. Dengan pemisahan ini, handler tidak pernah tahu nama tabel, tidak pernah menulis SELECT, dan tidak pernah memegang connection pool. Yang ia tahu hanya: panggil service, terima hasil, balas JSON.

Kenapa ini penting untuk online shop skincare? Katalog produk, varian, cart, checkout, inventory, payment, dan riwayat order akan terus bertambah kompleks. Kalau SQL menyebar di handler, setiap perubahan skema (menambah kolom compare_at_price_rupiah, mengubah index, memecah tabel) akan menyentuh banyak tempat sekaligus. Kalau SQL tinggal di repository, perubahan database terkurung di satu file per domain.

Repository adalah gerbang data, bukan otak domain

Repository bukan tempat semua logika bisnis. Ia adalah gerbang data: tahu cara membaca dan menulis baris, tetapi tidak tahu kenapa. Aturan “produk harus aktif sebelum bisa masuk cart” itu milik service, bukan repository.

flowchart LR
  FE["React Storefront"] -->|HTTP JSON| H["chi Handler"]
  H -->|panggil| S["Product Service"]
  S -->|interface| I["ProductRepository"]
  I -->|implementasi| P["pgProductRepository"]
  P -->|pgxpool / pgx.Tx| DB[("PostgreSQL")]
  I -. saat unit test .-> F["FakeProductRepository"]

Gambar 1. Aliran satu arah. Handler bergantung ke service, service bergantung ke interface repository, implementasi pgx berbicara ke PostgreSQL. Saat unit test, interface yang sama dipenuhi fake in-memory tanpa database.

Setiap lapis punya satu tanggung jawab yang tidak boleh bocor ke tetangganya. Inilah pembagian kerja yang dipakai di seluruh proyek skincare.

Interface ditulis dari kebutuhan service, bukan dari bentuk tabel

Interface repository didefinisikan di package domain (internal/product) dan menggambarkan apa yang service butuhkan, bukan apa yang kebetulan ada di database.

Di Go, interface dipenuhi secara implisit. Struct pgProductRepository tidak perlu menulis implements ProductRepository. Selama method-nya cocok (nama, parameter, return), ia otomatis memenuhi kontrak. Ini berbeda dari TypeScript dan PHP yang biasanya menulis relasi implements secara eksplisit, dan justru perbedaan inilah yang membuat fake repository di test jadi sangat murah dibuat.

Interface katalog skincare punya lima operasi utama: List, GetBySlug, Create, Update, dan Archive. Semua menerima context.Context sebagai parameter pertama agar timeout dan cancellation dari HTTP request terus terbawa sampai ke query PostgreSQL. Perhatikan juga parameter db database.Querier di setiap method: itulah kunci agar repository yang sama bisa dipakai di dalam maupun di luar transaksi, yang kita bahas tuntas di section 05.

internal/product/repository.goSalin
package product

import (
	"context"

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

// ProductRepository adalah kontrak akses data katalog.
// Diisi pgProductRepository (Postgres) di produksi dan FakeProductRepository di test.
type ProductRepository interface {
	List(ctx context.Context, db database.Querier, filter ProductFilter) ([]Product, error)
	GetBySlug(ctx context.Context, db database.Querier, slug string) (Product, error)
	Create(ctx context.Context, db database.Querier, params CreateProductParams) (Product, error)
	Update(ctx context.Context, db database.Querier, id int64, params UpdateProductParams) (Product, error)
	Archive(ctx context.Context, db database.Querier, id int64) error
}

Pola yang sama nanti dipakai untuk cart dan order. Nama method mengikuti bahasa domain, bukan selalu CRUD mentah. Cart butuh AddItem dan RemoveItem, sedangkan order butuh CreateFromCheckout dan ListByUserID.

internal/cart/repository.goSalin
package cart

import (
	"context"

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

type Repository interface {
	GetActiveByUserID(ctx context.Context, db database.Querier, userID int64) (Cart, error)
	AddItem(ctx context.Context, db database.Querier, params AddItemParams) (CartItem, error)
	UpdateItemQuantity(ctx context.Context, db database.Querier, itemID int64, quantity int) (CartItem, error)
	RemoveItem(ctx context.Context, db database.Querier, itemID int64) error
}

internal/order/repository.goSalin
package order

import (
	"context"

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

type Repository interface {
	Create(ctx context.Context, db database.Querier, params CreateOrderParams) (int64, error)
	CreateItem(ctx context.Context, db database.Querier, params CreateOrderItemParams) error
	FindByIdempotencyKey(ctx context.Context, db database.Querier, key string) (Order, error)
	ListByUserID(ctx context.Context, db database.Querier, userID int64, pagination Pagination) ([]Order, error)
}

Pisahkan model yang dibaca dari parameter yang menulis

Sebelum menulis query, kita pisahkan tiga bentuk data: struct domain yang dibaca, parameter untuk membuat, dan parameter untuk mengubah sebagian.

Product adalah bentuk data yang dipakai layer product. Sesuai skema kanonik proyek, katalog memakai id bigint, slug yang unik, brand_id, status (draft, active, archived), dan soft delete deleted_at. Harga tidak ada di products: harga adalah milik product_variants (price_rupiah bigint), karena varian (SKU) adalah unit yang benar-benar dijual. Uang selalu integer rupiah, tidak pernah float64.

internal/product/model.goSalin
package product

import "time"

// Product memetakan tabel products. Harga ada di product_variants, bukan di sini.
type Product struct {
	ID          int64      `json:"id"`
	BrandID     int64      `json:"brand_id"`
	Slug        string     `json:"slug"`
	Name        string     `json:"name"`
	Description string     `json:"description"`
	SkinTypes   []string   `json:"skin_types"`
	Concerns    []string   `json:"concerns"`
	Status      string     `json:"status"` // draft, active, archived
	CreatedAt   time.Time  `json:"created_at"`
	UpdatedAt   time.Time  `json:"updated_at"`
	DeletedAt   *time.Time `json:"deleted_at,omitempty"`
}

// ProductFilter adalah input baca List. Pointer berarti filter opsional.
type ProductFilter struct {
	BrandID *int64
	Status  *string
	Search  *string
	Limit   int
	Offset  int
}

// CreateProductParams adalah input tulis Create. Semua field wajib.
type CreateProductParams struct {
	BrandID     int64
	Slug        string
	Name        string
	Description string
	SkinTypes   []string
	Concerns    []string
	Status      string
}

// UpdateProductParams adalah input tulis Update parsial.
// Pointer nil berarti "field ini tidak diubah".
type UpdateProductParams struct {
	BrandID     *int64
	Slug        *string
	Name        *string
	Description *string
	Status      *string
}

internal/product/errors.goSalin
package product

import "errors"

// ErrProductNotFound adalah error domain, bukan error pgx.
// Handler memetakannya ke HTTP 404, bukan 500.
var ErrProductNotFound = errors.New("product not found")

Interface kecil yang dipenuhi *pgxpool.Pool dan pgx.Tx sekaligus

Di chapter Transaksi (R3C08) kita memperkenalkan database.Querier. Inilah detail yang membuat repository pattern ini istimewa: method repository yang sama bisa dijalankan di luar transaksi (langsung ke pool) maupun di dalam transaksi checkout (lewat tx), tanpa menggandakan kode.

Masalahnya begini. Kalau setiap method repository menulis r.pool.QueryRow(...), maka query itu terkunci ke pool dan tidak pernah ikut transaksi yang sedang berjalan. Saat checkout, service membuka satu pgx.Tx, dan semua operasi (kunci stok, insert order, insert order_items, tandai cart converted) harus jalan di tx yang sama agar atomik. Repository yang terkunci ke pool tidak bisa ikut.

Cara idiomatik Go menyelesaikan ini adalah sebuah interface kecil berisi method yang benar-benar dipakai. Karena *pgxpool.Pool dan pgx.Tx sama-sama punya Exec, Query, dan QueryRow dengan signature identik, satu interface bisa menerima keduanya. Implicit interface Go membuat keduanya memenuhi Querier tanpa deklarasi apa pun.

internal/database/dbtx.go (dari R3C08, dipakai ulang di sini)Salin
package database

import (
	"context"

	"github.com/jackc/pgx/v5"
	"github.com/jackc/pgx/v5/pgconn"
)

// Querier dipenuhi oleh *pgxpool.Pool maupun pgx.Tx.
// Repository menerima ini, sehingga method yang sama bisa dipakai
// untuk query biasa (pool) atau di dalam transaksi (tx).
type Querier interface {
	Exec(ctx context.Context, sql string, args ...any) (pgconn.CommandTag, error)
	Query(ctx context.Context, sql string, args ...any) (pgx.Rows, error)
	QueryRow(ctx context.Context, sql string, args ...any) pgx.Row
}

flowchart TD
  S["Service"] -->|"List(ctx, pool, filter)"| R["pgProductRepository"]
  S -->|"di dalam checkout:<br/>List(ctx, tx, filter)"| R
  R -->|"db.Query / db.QueryRow / db.Exec"| Q{"database.Querier"}
  Q -->|memenuhi| POOL["*pgxpool.Pool"]
  Q -->|memenuhi| TX["pgx.Tx"]
  POOL --> DB[("PostgreSQL")]
  TX --> DB

Gambar 2. Repository memanggil method lewat database.Querier. Service memutuskan: untuk pembacaan biasa ia mengoper pool, untuk checkout ia mengoper tx yang sedang terbuka. Method repository tidak berubah sama sekali.

Struct implementasi bergantung pada pool, kontrak tetap ProductRepository

Implementasi PostgreSQL boleh menyimpan *pgxpool.Pool di dalam struct-nya, tetapi kontrak yang dilihat service tetap ProductRepository. Constructor mengembalikan interface, bukan tipe konkret.

Struct pgProductRepository huruf kecil (unexported) karena tidak ada yang perlu menyebutnya dari luar package. Yang publik hanya constructor NewPostgresProductRepository, dan ia mengembalikan ProductRepository. Pool disimpan untuk satu hal saja: dipakai sebagai Querier default saat service tidak sedang dalam transaksi. Helper scan dan helper nullable di bawah ini akan dipakai berulang oleh method read dan write.

internal/product/pgx_repository.goSalin
package product

import (
	"context"
	"errors"
	"fmt"

	"github.com/jackc/pgx/v5"
	"github.com/jackc/pgx/v5/pgconn"
	"github.com/jackc/pgx/v5/pgxpool"

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

// pgProductRepository unexported: hanya constructor yang publik.
type pgProductRepository struct {
	pool *pgxpool.Pool
}

// NewPostgresProductRepository mengembalikan interface, bukan struct konkret.
func NewPostgresProductRepository(pool *pgxpool.Pool) ProductRepository {
	return &pgProductRepository{pool: pool}
}

// Pastikan saat compile bahwa pgProductRepository memenuhi ProductRepository.
var _ ProductRepository = (*pgProductRepository)(nil)

// productColumns dipakai konsisten oleh semua query baca dan RETURNING.
const productColumns = `id, brand_id, slug, name, description, skin_types, concerns, status, created_at, updated_at, deleted_at`

// scanProduct memetakan satu baris ke struct Product.
// pgx.Row dan pgx.Rows sama-sama punya Scan(dest ...any) error.
func scanProduct(row interface{ Scan(dest ...any) error }) (Product, error) {
	var p Product
	err := row.Scan(
		&p.ID,
		&p.BrandID,
		&p.Slug,
		&p.Name,
		&p.Description,
		&p.SkinTypes,
		&p.Concerns,
		&p.Status,
		&p.CreatedAt,
		&p.UpdatedAt,
		&p.DeletedAt,
	)
	if err != nil {
		return Product{}, err
	}
	return p, nil
}

// notFoundOnZeroRows menerjemahkan UPDATE/DELETE tanpa baris menjadi error domain.
func notFoundOnZeroRows(tag pgconn.CommandTag) error {
	if tag.RowsAffected() == 0 {
		return ErrProductNotFound
	}
	return nil
}

func ptrOrNil[T any](v *T) any {
	if v == nil {
		return nil
	}
	return *v
}

Query untuk banyak baris, QueryRow untuk satu baris

Untuk membaca banyak baris, gunakan Query, loop rows.Next, lalu tutup rows. Untuk satu baris, gunakan QueryRow dan terjemahkan pgx.ErrNoRows menjadi error domain ErrProductNotFound.

List memakai filter opsional brand_id, status, dan pencarian nama. Di katalog skincare, filter status dipakai agar storefront publik hanya melihat produk active, sementara dashboard admin bisa melihat draft juga. Limit dijaga agar client tidak menarik sejuta baris dalam satu request, dan pengurutan stabil pakai created_at DESC, id DESC.

internal/product/pgx_repository.goSalin
func (r *pgProductRepository) List(ctx context.Context, db database.Querier, filter ProductFilter) ([]Product, error) {
	limit := filter.Limit
	if limit <= 0 || limit > 100 {
		limit = 20
	}
	offset := filter.Offset
	if offset < 0 {
		offset = 0
	}

	query := `
SELECT ` + productColumns + `
FROM products
WHERE deleted_at IS NULL
  AND ($1::bigint IS NULL OR brand_id = $1)
  AND ($2::text   IS NULL OR status = $2)
  AND ($3::text   IS NULL OR name ILIKE '%' || $3 || '%')
ORDER BY created_at DESC, id DESC
LIMIT $4 OFFSET $5`

	rows, err := db.Query(ctx, query,
		ptrOrNil(filter.BrandID),
		ptrOrNil(filter.Status),
		ptrOrNil(filter.Search),
		limit,
		offset,
	)
	if err != nil {
		return nil, fmt.Errorf("list products: %w", err)
	}
	defer rows.Close()

	products := make([]Product, 0, limit)
	for rows.Next() {
		p, err := scanProduct(rows)
		if err != nil {
			return nil, fmt.Errorf("scan product: %w", err)
		}
		products = append(products, p)
	}
	if err := rows.Err(); err != nil {
		return nil, fmt.Errorf("iterate products: %w", err)
	}
	return products, nil
}

func (r *pgProductRepository) GetBySlug(ctx context.Context, db database.Querier, slug string) (Product, error) {
	query := `
SELECT ` + productColumns + `
FROM products
WHERE slug = $1 AND deleted_at IS NULL`

	p, err := scanProduct(db.QueryRow(ctx, query, slug))
	if errors.Is(err, pgx.ErrNoRows) {
		return Product{}, ErrProductNotFound
	}
	if err != nil {
		return Product{}, fmt.Errorf("get product by slug: %w", err)
	}
	return p, nil
}

INSERT ... RETURNING, UPDATE parsial dengan COALESCE, soft delete

Untuk operasi tulis yang perlu mengembalikan data terbaru, gunakan INSERT ... RETURNING dan UPDATE ... RETURNING. Untuk menghapus, proyek skincare memakai soft delete: isi deleted_at, bukan hapus baris.

Create mengembalikan produk yang baru dibuat, lengkap dengan id dan created_at yang dibangkitkan PostgreSQL. Update parsial memakai COALESCE($n, kolom) agar field yang nil (tidak dikirim) mempertahankan nilai lamanya. Archive adalah soft delete: ia mengisi deleted_at dan mengecek RowsAffected untuk membedakan “berhasil diarsipkan” dari “produk tidak ada”.

internal/product/pgx_repository.goSalin
func (r *pgProductRepository) Create(ctx context.Context, db database.Querier, params CreateProductParams) (Product, error) {
	query := `
INSERT INTO products (brand_id, slug, name, description, skin_types, concerns, status)
VALUES ($1, $2, $3, $4, $5, $6, $7)
RETURNING ` + productColumns

	p, err := scanProduct(db.QueryRow(ctx, query,
		params.BrandID,
		params.Slug,
		params.Name,
		params.Description,
		params.SkinTypes,
		params.Concerns,
		params.Status,
	))
	if err != nil {
		return Product{}, fmt.Errorf("create product: %w", err)
	}
	return p, nil
}

func (r *pgProductRepository) Update(ctx context.Context, db database.Querier, id int64, params UpdateProductParams) (Product, error) {
	query := `
UPDATE products
SET brand_id    = COALESCE($2::bigint, brand_id),
    slug        = COALESCE($3::text,   slug),
    name        = COALESCE($4::text,   name),
    description = COALESCE($5::text,   description),
    status      = COALESCE($6::text,   status),
    updated_at  = now()
WHERE id = $1 AND deleted_at IS NULL
RETURNING ` + productColumns

	p, err := scanProduct(db.QueryRow(ctx, query,
		id,
		ptrOrNil(params.BrandID),
		ptrOrNil(params.Slug),
		ptrOrNil(params.Name),
		ptrOrNil(params.Description),
		ptrOrNil(params.Status),
	))
	if errors.Is(err, pgx.ErrNoRows) {
		return Product{}, ErrProductNotFound
	}
	if err != nil {
		return Product{}, fmt.Errorf("update product: %w", err)
	}
	return p, nil
}

func (r *pgProductRepository) Archive(ctx context.Context, db database.Querier, id int64) error {
	query := `
UPDATE products
SET deleted_at = now(), status = 'archived', updated_at = now()
WHERE id = $1 AND deleted_at IS NULL`

	tag, err := db.Exec(ctx, query, id)
	if err != nil {
		return fmt.Errorf("archive product: %w", err)
	}
	return notFoundOnZeroRows(tag)
}

pgx adalah detail implementasi, bukan bagian dari kontrak

Aturan emas repository pattern: tipe pgx (seperti pgx.ErrNoRows, pgconn.PgError, pgx.Rows) hidup di dalam implementasi, tidak boleh keluar ke service atau handler. Service tahu ErrProductNotFound, bukan pgx.ErrNoRows.

Kalau service ikut errors.Is(err, pgx.ErrNoRows), maka service tahu-tahu bergantung pada pgx. Suatu hari kamu mau menambah cache, atau mengganti pgx, atau mengetes service dengan fake, dan tiba-tiba semua tempat yang menyentuh pgx.ErrNoRows ikut rusak. Repository-lah yang menerjemahkan error pgx menjadi error domain di perbatasan.

flowchart LR
  subgraph domain["Domain (bersih dari pgx)"]
    H["Handler"]
    S["Service"]
    E["ErrProductNotFound"]
  end
  subgraph impl["Implementasi (boleh pgx)"]
    R["pgProductRepository"]
    PGX["pgx.ErrNoRows<br/>pgconn.PgError"]
  end
  H --> S
  S --> R
  R -->|terjemahkan di sini| E
  PGX -.->|tidak pernah lewat| S

Gambar 3. Garis batas. pgx hidup di kanan (implementasi). Error pgx diterjemahkan menjadi error domain (ErrProductNotFound) di repository, sehingga service dan handler di kiri tetap bersih dan bisa dites tanpa pgx.

Contoh nyata: pelanggaran unique constraint pada products.slug. PostgreSQL membalas SQLSTATE 23505. Repository menangkapnya dan mengubahnya menjadi error domain ErrSlugTaken, sehingga handler bisa membalas HTTP 409 Conflict, bukan 500.

internal/product/errors.goSalin
package product

import "errors"

var (
	ErrProductNotFound = errors.New("product not found")
	ErrSlugTaken       = errors.New("product slug already taken")
)

internal/product/pgx_repository.go (penanganan unique violation)Salin
import "github.com/jackc/pgx/v5/pgconn"

// translateWriteError mengubah error pgx jadi error domain di perbatasan.
func translateWriteError(err error) error {
	var pgErr *pgconn.PgError
	if errors.As(err, &pgErr) && pgErr.Code == "23505" {
		// 23505 = unique_violation. products.slug UNIQUE.
		return ErrSlugTaken
	}
	return err
}

Dengan helper itu, Create cukup membungkus error tulisnya: return Product{}, translateWriteError(fmt.Errorf("create product: %w", err)). Service tidak pernah melihat pgconn.PgError, hanya ErrSlugTaken yang ia mengerti.

Wiring manual yang jelas, tanpa container ajaib

Dependency injection di Go biasanya manual, sederhana, dan terlihat jelas dari constructor. Tidak ada service container yang menyelesaikan dependency otomatis, dan untuk modular monolith itu justru kelebihan.

Service menerima ProductRepository (interface), bukan *pgProductRepository (konkret). Handler menerima *ProductService, bukan pool. Untuk pembacaan biasa, service mengoper s.pool sebagai Querier. Hanya saat checkout (di package order) service mengoper tx. Rantai dependency disusun sekali di cmd/api/main.go.

internal/product/service.goSalin
package product

import (
	"context"
	"fmt"
	"strings"

	"github.com/jackc/pgx/v5/pgxpool"
)

type ProductService struct {
	pool *pgxpool.Pool
	repo ProductRepository
}

func NewProductService(pool *pgxpool.Pool, repo ProductRepository) *ProductService {
	return &ProductService{pool: pool, repo: repo}
}

func (s *ProductService) ListProducts(ctx context.Context, filter ProductFilter) ([]Product, error) {
	// Pembacaan biasa: oper pool sebagai Querier.
	return s.repo.List(ctx, s.pool, filter)
}

func (s *ProductService) GetProduct(ctx context.Context, slug string) (Product, error) {
	if strings.TrimSpace(slug) == "" {
		return Product{}, ErrProductNotFound
	}
	return s.repo.GetBySlug(ctx, s.pool, slug)
}

func (s *ProductService) CreateProduct(ctx context.Context, params CreateProductParams) (Product, error) {
	if strings.TrimSpace(params.Name) == "" {
		return Product{}, fmt.Errorf("product name is required")
	}
	if strings.TrimSpace(params.Slug) == "" {
		return Product{}, fmt.Errorf("product slug is required")
	}
	return s.repo.Create(ctx, s.pool, params)
}

internal/product/handler.goSalin
package product

import (
	"errors"
	"net/http"

	"github.com/go-chi/chi/v5"

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

type Handler struct {
	service *ProductService
}

func NewHandler(service *ProductService) *Handler {
	return &Handler{service: service}
}

func (h *Handler) Detail(w http.ResponseWriter, r *http.Request) {
	slug := chi.URLParam(r, "slug")

	p, err := h.service.GetProduct(r.Context(), slug)
	if errors.Is(err, ErrProductNotFound) {
		httpx.Error(w, http.StatusNotFound, "product_not_found", "produk tidak ditemukan")
		return
	}
	if err != nil {
		httpx.Error(w, http.StatusInternalServerError, "internal_error", "gagal memuat produk")
		return
	}

	httpx.Data(w, http.StatusOK, p)
}

Inilah titik di mana koneksi pgx (R3C05) bertemu repository. Pool dibuka sekali, lalu disuntikkan ke setiap repository dan service. Penutupan pool ditunda dengan defer pool.Close() agar koneksi dikembalikan rapi saat aplikasi berhenti.

cmd/api/main.goSalin
package main

import (
	"context"
	"log/slog"
	"net/http"
	"os"
	"time"

	"github.com/jackc/pgx/v5/pgxpool"

	"github.com/kamu/skincare-backend/internal/cart"
	"github.com/kamu/skincare-backend/internal/inventory"
	"github.com/kamu/skincare-backend/internal/order"
	"github.com/kamu/skincare-backend/internal/payment"
	"github.com/kamu/skincare-backend/internal/product"
)

func main() {
	ctx := context.Background()

	pool, err := pgxpool.New(ctx, os.Getenv("DATABASE_URL"))
	if err != nil {
		slog.Error("open pool", "error", err)
		os.Exit(1)
	}
	defer pool.Close()

	if err := pool.Ping(ctx); err != nil {
		slog.Error("ping db", "error", err)
		os.Exit(1)
	}

	// --- Wiring per domain: repository -> service -> handler ---
	productRepo := product.NewPostgresProductRepository(pool)
	productSvc := product.NewProductService(pool, productRepo)
	productHandler := product.NewHandler(productSvc)

	cartRepo := cart.NewPostgresRepository(pool)
	inventoryRepo := inventory.NewPostgresRepository(pool)
	orderRepo := order.NewPostgresRepository(pool)
	paymentRepo := payment.NewPostgresRepository(pool)

	// Service checkout memegang pool untuk membuka transaksi sendiri,
	// lalu mengoper tx ke cart/inventory/order/payment repository.
	orderSvc := order.NewService(pool, cartRepo, inventoryRepo, orderRepo, paymentRepo)
	orderHandler := order.NewHandler(orderSvc)

	_ = productHandler
	_ = orderHandler

	addr := ":8080"
	slog.Info("server listening", "addr", addr)
	srv := &http.Server{Addr: addr, ReadHeaderTimeout: 5 * time.Second}
	if err := srv.ListenAndServe(); err != nil {
		slog.Error("server stopped", "error", err)
		os.Exit(1)
	}
}

Uji aturan bisnis service tanpa PostgreSQL

Kekuatan repository interface paling terasa saat service bisa dites tanpa PostgreSQL, tanpa migration, tanpa Docker, dan tanpa fixture database. Cukup fake repository in-memory yang memenuhi interface yang sama.

Fake repository menyimpan data di map dan mengabaikan parameter db database.Querier (ia tidak butuh database). Ini bukan pengganti integration test, tetapi cukup cepat untuk menguji aturan bisnis service ribuan kali per detik. Integration test repository terhadap PostgreSQL asli tetap dibuat di Roadmap 6.

internal/product/fake_repository.goSalin
package product

import (
	"context"
	"sync"

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

// FakeProductRepository memenuhi ProductRepository tanpa database.
type FakeProductRepository struct {
	mu       sync.Mutex
	nextID   int64
	bySlug   map[string]int64
	products map[int64]Product
}

func NewFakeProductRepository() *FakeProductRepository {
	return &FakeProductRepository{
		nextID:   1,
		bySlug:   make(map[string]int64),
		products: make(map[int64]Product),
	}
}

var _ ProductRepository = (*FakeProductRepository)(nil)

func (f *FakeProductRepository) List(ctx context.Context, _ database.Querier, filter ProductFilter) ([]Product, error) {
	f.mu.Lock()
	defer f.mu.Unlock()

	out := make([]Product, 0, len(f.products))
	for _, p := range f.products {
		if filter.Status != nil && p.Status != *filter.Status {
			continue
		}
		out = append(out, p)
	}
	return out, nil
}

func (f *FakeProductRepository) GetBySlug(ctx context.Context, _ database.Querier, slug string) (Product, error) {
	f.mu.Lock()
	defer f.mu.Unlock()

	id, ok := f.bySlug[slug]
	if !ok {
		return Product{}, ErrProductNotFound
	}
	return f.products[id], nil
}

func (f *FakeProductRepository) Create(ctx context.Context, _ database.Querier, params CreateProductParams) (Product, error) {
	f.mu.Lock()
	defer f.mu.Unlock()

	if _, taken := f.bySlug[params.Slug]; taken {
		return Product{}, ErrSlugTaken
	}
	p := Product{
		ID:          f.nextID,
		BrandID:     params.BrandID,
		Slug:        params.Slug,
		Name:        params.Name,
		Description: params.Description,
		SkinTypes:   params.SkinTypes,
		Concerns:    params.Concerns,
		Status:      params.Status,
	}
	f.products[p.ID] = p
	f.bySlug[p.Slug] = p.ID
	f.nextID++
	return p, nil
}

func (f *FakeProductRepository) Update(ctx context.Context, _ database.Querier, id int64, params UpdateProductParams) (Product, error) {
	f.mu.Lock()
	defer f.mu.Unlock()

	p, ok := f.products[id]
	if !ok {
		return Product{}, ErrProductNotFound
	}
	if params.Name != nil {
		p.Name = *params.Name
	}
	if params.Status != nil {
		p.Status = *params.Status
	}
	f.products[id] = p
	return p, nil
}

func (f *FakeProductRepository) Archive(ctx context.Context, _ database.Querier, id int64) error {
	f.mu.Lock()
	defer f.mu.Unlock()

	p, ok := f.products[id]
	if !ok {
		return ErrProductNotFound
	}
	p.Status = "archived"
	f.products[id] = p
	return nil
}

internal/product/service_test.goSalin
package product

import (
	"context"
	"errors"
	"testing"
)

func TestProductService_CreateProduct_Success(t *testing.T) {
	repo := NewFakeProductRepository()
	svc := NewProductService(nil, repo) // pool nil: fake mengabaikan Querier

	got, err := svc.CreateProduct(context.Background(), CreateProductParams{
		BrandID: 1,
		Slug:    "hydrating-toner",
		Name:    "Hydrating Toner",
		Status:  "active",
	})
	if err != nil {
		t.Fatalf("CreateProduct error: %v", err)
	}
	if got.ID == 0 {
		t.Fatal("expected generated product id")
	}
	if got.Slug != "hydrating-toner" {
		t.Fatalf("expected slug hydrating-toner, got %q", got.Slug)
	}
}

func TestProductService_CreateProduct_RejectsEmptyName(t *testing.T) {
	svc := NewProductService(nil, NewFakeProductRepository())

	_, err := svc.CreateProduct(context.Background(), CreateProductParams{Slug: "x", Name: "  "})
	if err == nil {
		t.Fatal("expected error for empty name")
	}
}

func TestProductService_GetProduct_NotFound(t *testing.T) {
	svc := NewProductService(nil, NewFakeProductRepository())

	_, err := svc.GetProduct(context.Background(), "missing-slug")
	if !errors.Is(err, ErrProductNotFound) {
		t.Fatalf("expected ErrProductNotFound, got %v", err)
	}
}

Satu domain, satu package, file yang berubah bersama

Setiap domain mengumpulkan model, interface, implementasi pgx, service, handler, dan test di satu package. File yang berubah bersama hidup berdekatan.

Pola per file di dalam satu domain konsisten: model.go memegang struct domain dan parameter, errors.go memegang error domain, repository.go memegang interface, pgx_repository.go memegang implementasi Postgres (satu-satunya file yang import pgx), service.go memegang aturan bisnis, dan handler.go memegang HTTP. Test hidup di package yang sama agar bisa menguji fungsi unexported.

Kesalahan klasik saat datang dari ekosistem ORM dan framework penuh

Repository pattern sederhana, tetapi ada beberapa kesalahan yang sering muncul saat datang dari Eloquent, Prisma, atau framework yang mengurus database secara ajaib.

Sambungkan koneksi, query, write, dan transaksi jadi satu modul

Latihan ini menyambungkan seluruh Roadmap 3 menjadi satu lapis akses data product yang bersih dan testable, lalu menjalankan unit test tanpa database.

Verifikasi lapis sudah bersih dengan satu pemeriksaan cepat: tidak ada import pgx di luar pgx_repository.go dan internal/database.

TerminalSalin
# Pastikan SQL hanya di repository (tidak ada di handler/service)
grep -rn "pool.Query\|pool.Exec\|SELECT \|INSERT \|UPDATE " internal/product/handler.go internal/product/service.go

# Pastikan pgx tidak bocor ke service/handler
grep -rn "jackc/pgx" internal/product/service.go internal/product/handler.go

# Jalankan unit test service (tanpa database)
go test ./internal/product/...

Kalau dua grep pertama tidak menghasilkan baris apa pun dan go test lulus, lapis repository-mu sudah bersih dan testable.

TerminalSalin
ok      github.com/kamu/skincare-backend/internal/product    0.012s

Repository pattern adalah capstone yang menyatukan koneksi, query, write, transaksi, dan index Roadmap 3 menjadi satu lapis akses data yang bersih, dan jembatan menuju Clean Architecture di Roadmap 4.

Di proyek online shop skincare, pola ini menjadi standar untuk product, cart, order, inventory, payment, shipment, review, dan promotion. Di Roadmap 4, kita menaikkan pola ini menjadi Clean Architecture modular monolith yang punya boundary domain tegas, error mapping terpusat, logging terstruktur, config, dan wiring aplikasi yang lebih matang. Repository yang kamu tulis hari ini akan tetap dipakai apa adanya, hanya dibungkus lebih rapi.

Rujukan resmi yang relevan: Go 1.26 release notes, pgx v5, pgxpool v5, dan pgconn (PgError, CommandTag).