Use packages as layers: https://www.gobeyond.dev/packages-as-layers/ https://www.gobeyond.dev/packages-as-layers/ and you can probably write arbitrarily large G

Use packages as layers: https://www.gobeyond.dev/packages-as-layers/ https://www.gobeyond.dev/packages-as-layers/ and you can probably write arbitrarily large Go systems, or at least, well beyond a point where most projects get. A lot of the problem emerges if you try to use some organizational pattern that, without you perhaps realizing it, is foundationally based on being able to have circular dependencies, or otherwise working poorly with Go's visibility rules. I have found myself becoming increasingly disenchanted with all the heavyweight design methodologies over the years anyhow. They amount to a claim: "All problems you may ever face have this structure and as a result this is the optimal structure to meet those problems with code." The problem is that first bit is wrong. Problems have all kinds of different structures. Start with the layered approach and your code will naturally follow the faultlines of the problem, whatever it may be. Try to jam the code into a particular structure up front and you just have to hope that it is the right one; you won't know until you've put a lot of work in, and, almost certainly for any non-trivial project, there will be at least one major component for which it is actually wrong. (And often it's just wrong across the board.) Worse, people who get too focused on a particular up-front highly-structured design lose the ability to even realize that their structure is the wrong structure; it starts becoming the very lens through which they see the world.