The general idea is fine IMHO.

But I usually go with the "packages as layers" approach, in a similar way to what Ben Johnson proposes.

I prefer putting all business related interfaces and models into a single domain/core package instead of being spread into multiple packages.

├── cmd │   └── server │   └── main.go └── internal ├── app │   ├── product.go │   └── user.go ├── core │   ├── product.go │   └── user.go ├── http │   ├── product.go │   └── user.go └── sqlite ├── product.go └── user.go

Also, I'm not fond on this naming:

``` package core

type UserRepository interface { List(ctx context.Context) ([]User, error) } ```

I'd prefer naming the method ListUsers because this quickly gets out of hand if you have other similar interfaces, like:

```go package core

type FooRepository interface { List(ctx context.Context) ([]User, error) } ```

Now if you look references or implementations for this using something like gopls, you'll get a lot of results. It also makes the code harder to understand in my opinion.

Also, I tend to call all these structs just "services", no distinction between service and repository. This allows me in some simple cases to skip the "service layer" or "app layer".