Project layout

Organize your code by features, not by technical layers.
This probably matters more in Go than in other languages, because in Go a package is the directory, the namespace and the visibility boundary at the same time.

If the top-level folders are controllers/, services/ and repositories/, you can't tell what the product actually does. It reads awkward and is confusing as well - remember the naming rules we previously discussed?
Avoid cross imports between features. If one feature needs another, it goes through a small client the other feature exposes, or a shared contract in internal/.

Each feature is like a slice from vertical-slices, and it owns its whole stack (routing, validation, business logic, persistence) in one directory, so changing one feature does not touch the other one - more on this in the next post.

This turns to be very useful when a feature has to become its own service. Moving discount/ feature out is a package move and a few lines of wiring removed from cmd/.

Always ask yourself this question: If you had to move one feature into its own service tomorrow, how many directories would you touch?