Package hierarchy of large scale projects

I want to work on a large scale project. For the sake of common programming paradigms, I want to divide my project into packages. An example is as follows:

project/
    domain/
    utils/
    system/

The Go packaging system seems to be not appropriate for this kind of packaging. Each package is assumed to be standalone packages. But when dealing with a large scale project, one may have to use packages somehow dependent to each other. There are several reasons to build a hierarchy like this:

• Loosely coupled code
• Logical separation of code base
• Managing whole project in a single VCS repository

So, is this possible in Go or should I just adapt myself to package everything under GOPATH? In this case, I have to create a repository for each package and there will be packages that importable from irrelevant packages but meaningless mechanic for them.

Each package (besides main) in Go behaves like a library.

You should compose your packages as you would produce a library. It looks to be very simple and valid approach - it follows main Go principles. A library should know everything about itself.

> But when dealing with a large scale project, one may have to use packages somehow dependent to each other.

This looks like a spot of problems. Why you will like to have two packages (a and b) which depend on themselves (a requires b and b requires a) - it's against one of the Go principles (circular dependency). If you anyhow think about this usage, then you should merge those packages.

If you are still unsure how to compose packages - then look at Go standard library. Good example might by http package.

In our project we want to separate application types (model) into separate package, so we can use them in other applications of a project. You need to think which part of you project you want to use as an application, and which as a library/driver.

> Loosely coupled code

Practically, there is no limit in files number in the same package (directory).<br />
[update] Package is a bunch of files within the same directory. Packages / directories can be nested.

> Managing whole project in a single VSC repository

There is nothing which may stop you to keep all libraries from the project in a single repository. Go std packages (there are dozens of them) are in a single repository.

[update] Also you need to understand difference between packages and how go get resolves / fetch them. go get is a tool which interprets import paths and handles ones with supported prefix (eg: github, bitbucket .... - you can read about them in go get docs). So if a packages starts with github/user/name it clones whole repository locally using HTTPS.

So for example I have two packages in the same repository:

• "github.com/scale-it/go-web"
• "github.com/scale-it/go-web/handlers"

And go get understand them and clone only once (under $GOPATH/src directory)