The example is a very simple one, and the author puts their code into packages named based on the layer they are in. I like Uncle Bob's idea that an application's architecture should clearly communicate its intent. So I'd like my application to have top-level packages based on domain areas. So my file structure would look something like this:
/Customers /domain.go /interactor.go /interface.go /repository.go /... the same for other domain areas
The problem with this is that multiple layers share the same package. So it's not all that clear when the dependency rule is being violated, because you don't have imports showing what depends on what.
I'm coming from a Python background, where this wouldn't be as much of an issue, because you can import individual files, so
We could achieve something similar in gO by nesting packages, so that the customers package contains a domain package and an interactor package, and so on. This feels clunky, and identically named packages can be annoying to deal with.
Another option would be to make multiple packages per domain area. One called customer_domain, one called customer_interactor, etc. But this feels dirty as well. It doesn't fit well with Go's package naming guidelines, and looks like all of these separate packages should somehow be grouped, since their names have a common prefix.
So what would be a good file layout for this?