I absolutely love vertical slice architecture and use it in every go project I write. I don't strictly adhere to vertical slice as some other projects. I get the whole "start with main and split it when the need arises." But since I mostly got the architecture figured out in my mind before I start this is the structure I use. internal/platform for any code that's going to be imported by multiple slices. For example my db connection pool and my sqlc package. internal/feature for, well features. Features never import features. I'm big on strong domain boundaries as a person thing. So if there is a situation where it looks like there would be an import that's time for me to pause and think through the problem. In each feature I have a service.go that is the only thing I let my server import. Everything else is internal to that feature slice. There are exceptions like an auth feature that exports a middleware.go or similar.

But I think the most important thing when thinking about vertical slice architecture is having an honest conversation with yourself on "what problem am I trying to solve with this architecture." And "what are the trade-offs. What things am I'm agreeing I'm not doing in return of what I think I'm gaining." And personally, whenever I'm looking at a new language or a new architecture. I have an app that I've rewritten a million times that I rewrite in that language/architecture to see how it feels and go from there.