组织Go程序-软件包或其他内容？

I have read the Go Tour and Googled "golang packages" but I have not yet found any advice about best practice in Go for organising moderately sized applications.

If I have an application that conceptually has several distinct parts, perhaps 10^3-10^4 LOC, and I don't intent to create reusable libraries for use in other applications, should all the source code files be package main?

To clarify ...

For example, lets say my program will have the following major chunks:

  • Something that manages a bunch of persistently stored data
    • allowing usual create, read, update, delete operations
  • Something that allows a human to view the stored data
  • Something that coordinates / mediates between these
  • Something that periodically fetches data updates from a web-service using SOAP.

So that would be MVC plus a fetcher of data.

From looking around at what people do, I now suspect I should

  • create $GOPATH/src/myprogramname
  • in there put some main.go with package main and func main() { ... } in it.
  • create some subdirectories like
    • $GOPATH/src/myprogramname/model
    • $GOPATH/src/myprogramname/view
    • $GOPATH/src/myprogramname/control
    • $GOPATH/src/myprogramname/fetch
  • have the .go files in those subdirectories begin with package fetch, etc. Where the package name always matches the subdirectory name.
  • my main.go will probably import ( ... "fetch"; "model"; "view"; "control" )
  • as main.go grows, split it into other reasonably sized .go files named according to purpose.

  • build the program, including *.go in the above package subdirectories by

     cd $GOPATH/src/myprogramname
 go build

Is that all I need to do? Is that the properly idiomatic Go way of organising things? Is there more I should know or be thinking of? Is there some canonical webpage or PDF I overlooked and should read to find out this stuff?

In short, I don't want a 10,000 line main.go with everything in it. What are the idiomatic Go principles for organising code into files, subdirectories, packages and any other organisational units corresponding to normal conceptual divisions according to well-known structured-programming and/or OO principles?

You could break down your project into several layers based on the encapsulation level of your functions, i.e. having low-level functions in separate packages and logic functions in your main package. (You could inspire yourself of MVC-like architectures) Since we don't have any details about your code, it is hard to see what kind of architecture would be best suited.

But in the end your choice will be based on the code simplicity / re-usability balance.

The general "best practice" in Go seems to be having each package provide a type or a service. Most of the packages in the standard library expose one or two types, and functions for working with those types. Some, like net/http and testing, provide a service - not in the "microservices" sense of something executable in itself, but rather a set of functionality related to a specific activity.