Package Naming

[light nymph]

Hey, I'm trying to understand best practice around package naming and project structure.

I've read the explanation here - https://go.dev/doc/effective_go#package-names and think I have a decent grasp, but just wanted to clarify something.

Say I'm wanting to create repositories to help facilitate communication with the database. I've got a directory path like database/repositories and then say I want to have a user repository and a customer repository. Is best practice to have a user.go file and then a customer.go file, each with same package name repositories, so that in code I can reference them as repositories.User and repositories.Customer?

the alternative I could imagine to my setup would be a single repositories.go file (matching the package name) with all the different repo's I need defined inside

is one better than the other? mostly seeking clarity on what is the standard/consistent across most projects

[warm hornet]

Hi bro! I usually follow the structure below to keep these repository calls idiomatic: repository.X. However, without keeping them in the same structure, of course, if you need both repositories in the same file, you can rename them with aliases, which is recommended.

Internal
common
repositories
your_interface_contract.go
repository_impl.go
user
infrastructure
repository
user.go
order
infrastructure
repository
order.go

[light nymph]

thanks, that's helpful. i've also been bouncing around different project layouts a bit as well. with your layout what else do you consider "internal"? would that include things like domain models, api handlers etc.?

[rugged hollow]

yes do this

internal is a module private package (only can be accessed from inside the module). It is not very useful unless you are distributing a library for others to use

if you want a bit more nuance, what we usually recommend here is going a bit more specific though

drop the 'database' part

/repository
    /postgres
        user.go
        orders.go
   /redis
      user.go

the types in here end up being postgres.UserRepository and redis.UserRepository

which really is what you probably actually want to express

since you can have multiple implementations of the same repository

these types then implement interfaces