How would you design the data access layer of a Go service for testability and flexibility using the repository pattern?

Question

Accepted Answer

// 1. Define the interface in the domain/service layer
type UserRepository interface {
    FindByID(ctx context.Context, id string) (*User, error)
    FindByEmail(ctx context.Context, email string) (*User, error)
    Create(ctx context.Context, user *User) error
    Update(ctx context.Context, user *User) error
    Delete(ctx context.Context, id string) error
}

// 2. Implement with Postgres
type postgresUserRepo struct {
    db *sql.DB
}

func NewPostgresUserRepo(db *sql.DB) UserRepository {
    return &postgresUserRepo{db: db}
}

func (r *postgresUserRepo) FindByID(ctx context.Context, id string) (*User, error) {
    u := &User{}
    err := r.db.QueryRowContext(ctx,
        "SELECT id, name, email FROM users WHERE id = $1", id,
    ).Scan(&u.ID, &u.Name, &u.Email)
    if errors.Is(err, sql.ErrNoRows) {
        return nil, ErrNotFound
    }
    return u, err
}

// 3. Service receives interface — not concrete type
type UserService struct {
    repo UserRepository
    log  *slog.Logger
}

func NewUserService(repo UserRepository, log *slog.Logger) *UserService {
    return &UserService{repo: repo, log: log}
}

// 4. Mock for tests
type mockUserRepo struct {
    users map[string]*User
}
func (m *mockUserRepo) FindByID(_ context.Context, id string) (*User, error) {
    u, ok := m.users[id]
    if !ok { return nil, ErrNotFound }
    return u, nil
} sqlc generates type-safe Go functions from SQL queries — no reflection, full IDE support One repository interface per aggregate (User, Order, Product) — not one god repository Return domain errors (ErrNotFound) not database errors — decouple domain from persistence Integration tests use testcontainers-go for a real Postgres — unit tests use mocks Avoid leaking DB types (sql.NullString) into domain models — map at the repository layer

How would you design the data access layer of a Go service for testability and flexibility using the repository pattern?

Define a Repository interface per domain aggregate, implement with sql.DB, inject via constructor, and use sqlc for type-safe query generation. Tests use mock implementations or in-process SQLite.

How would you design the data access layer of a Go service for testability and flexibility using the repository pattern?

Define a Repository interface per domain aggregate, implement with sql.DB, inject via constructor, and use sqlc for type-safe query generation. Tests use mock implementations or in-process SQLite.

Scenario Questions

Follow-up Questions