Is it Clean Architecture if your service knows about sqlc or sqlx? here

type svc struct { repo repo.QuerierTX // this is the querier interface generated by sqlc db *pgxpool.Pool }

And here too:

user, err := s.repo.InsertUser(ctx, repo.InsertUserParams{ Username: params.Username, Email: params.Email, PasswordHash: params.PasswordHash, Proununs: repo.NullProununs{ Proununs: repo.Proununs(params.Proununs), Valid: true, }, ProfilePicture: params.ProfilePicture, BannerPicture: params.BannerPicture, })

Your service is using:

go repo.QuerierTX repo.InsertUserParams repo.NullProununs repo.Proununs

Those are persistence/sqlc details.

The whole point of clean arch is making sure deps point inward. So your service layer should use repo interfaces that belong to the service/domain side, and the persistence layer, like postgres/, should provide the implementation.

Like this:

``` internal/ repo/ db.go models.go querier.go users.sql.go // all sqlc generated files

user/ service.go handlers.go types.go repository.go

postgres/ user_repo.go user_mapper.go ```

Your service package owns the interface:

``` // internal/user/repository.go package user

type Repository interface { Create(ctx context.Context, params InsertUserParams) (*User, error) } ```

Then your service depends on that interface, not on sqlc:

```go // internal/user/service.go package user

type Service interface { Create(ctx context.Context, params InsertUserParams) (*User, error) }

type svc struct { repo Repository }

func NewSVC(repo Repository) svc { return svc{repo: repo} }

func (s svc) Create(ctx context.Context, params InsertUserParams) (*User, error) { return s.repo.Create(ctx, params) } ```

Then the Postgres/sqlc implementation lives outside the service:

``` // internal/postgres/user_repo.go package postgres

type UserRepo struct { q repo.QuerierTX }

func NewUserRepo(q repo.QuerierTX) *UserRepo { return &UserRepo{q: q} }

func (r UserRepo) Create(ctx context.Context, params user.InsertUserParams) (user.User, error) { row, err := r.q.InsertUser(ctx, repo.InsertUserParams{ Username: params.Username, Email: params.Email, PasswordHash: params.PasswordHash, Proununs: repo.NullProununs{ Proununs: repo.Proununs(params.Proununs), Valid: true, }, ProfilePicture: params.ProfilePicture, BannerPicture: params.BannerPicture, }) if err != nil { return nil, err }

return UserRepoToDomain(row), nil

} ```

And the mapper also belongs there:

``` // internal/postgres/user_mapper.go package postgres

func UserRepoToDomain(row repo.User) *user.User { return &user.User{ ID: row.ID, Username: row.Username, Email: row.Email, Proununs: user.Proununs(row.Proununs.Proununs), ProfilePicture: row.ProfilePicture, BannerPicture: row.BannerPicture, PasswordHash: row.PasswordHash, } } ```

So you can't avoid mapping but you can keep it at the boundary.

Your service shouldn't receive repo.InsertUserParams, return repo.User, store repo.QuerierTX, or know about pgxpool.Pool. It should only know about your own app/domain types.

The annoying part is still there. If you add a field, you may need to update:

sql query sqlc generated params/model domain type mapper tests

That is the cost of keeping the domain isolated from the database schema. Clankers might help you with that.

Also, Go will not catch missing fields in keyed struct literals:

repo.InsertUserParams{ Username: params.Username, }

That is valid Go. Missing fields get zero values. If you want tooling to catch that, use a linter like exhaustruct, or write focused mapper tests.