I am porting a large web application to Go. In order to manage complexity and increase testability, we are employing a service-oriented architecture. I am trying to figure out the clearest way to name and structure packages such that no service has any knowledge of another's implementation and that I can tell them apart at the application level. Allow me to give an example:
FooService
package api
type FooService interface {
foo()
}
FooService Implementation
package implementation
import (
"fmt"
_ "github.com/user/foo/api"
)
type FooImplementation struct {
}
func (self FooImplementation) foo() {
fmt.Println("foo")
}
In my application, I will need to bind this implementation to the interface, as well as numerous others. But they can't all be named api/implementation. Do I have too name the packages fooapi and fooimplementation? Or is there a better way to structure my application? Thanks!
I found a potential workaround but I'm not going to mark this closed because it's not ideal. I discovered that you can name your imports to disambiguate packages with the same name. E.g.
import (
fapi "github.com/user/foo/api"
fimplementation "github.com/user/foo/implementation"
)