I think it’s risible to state something grandiose like: “The project structure is designed with independent packages in mind, according to hexagonal architecture, and targeted to provide […] benefits” when your structure has 5 folders and contains just README files with no Go code, not even an example.
And I see no reason why the pkg folder exists. Making the default way to start a package the “enterprisey” way is a bad idea in my opinion.
My limited defense of pkg is that you end up with a lot of stuff in the root of a project anyway, so for an application, it can be nice to shove things down one level. But it’s probably not necessary for most applications.
Premature organization like premature optimization and premature abstraction makes simple code (or code that should be simple) more difficult to digest.
Start out flat, let the evolving code dictate package structure rather than the other way around. With the excellent editing and refactoring tools we have these days there is no reason not to.
Precisely! I always start with a single main.go and go from there. Add structure to your project as it evolves. And don’t be afraid to change it. I realise it might be harder for larger projects, but harder is not impossible.
Oh God, not another. :)
I think it’s risible to state something grandiose like: “The project structure is designed with independent packages in mind, according to hexagonal architecture, and targeted to provide […] benefits” when your structure has 5 folders and contains just README files with no Go code, not even an example.
And I see no reason why the pkg folder exists. Making the default way to start a package the “enterprisey” way is a bad idea in my opinion.
I’ve never cared for the pkg folder either. It seems redundant at best, or confusing at worst. I just use the root as my lib and types package.
My limited defense of pkg is that you end up with a lot of stuff in the root of a project anyway, so for an application, it can be nice to shove things down one level. But it’s probably not necessary for most applications.
Premature organization like premature optimization and premature abstraction makes simple code (or code that should be simple) more difficult to digest.
Start out flat, let the evolving code dictate package structure rather than the other way around. With the excellent editing and refactoring tools we have these days there is no reason not to.
agreed. sometimes prematurely organizing the code into endless subfolders can make a new project harder to dive into.
Precisely! I always start with a single
main.goand go from there. Add structure to your project as it evolves. And don’t be afraid to change it. I realise it might be harder for larger projects, but harder is not impossible.