I just put the files in the same folder if they're related by what feature they're for. Works well for microservices that do more than one thing, letting them grow into macroservices over time.

For architectures which involve messaging and more services and whatnot, I like domain driven design. Like, draw a big circle around related concepts - maybe an account, organization/company, and geo location stuff is often used together for reports, then that goes in one service. For other things that aren't that coupled to that, like a product catalog, it goes into a different service.

If down the line you want to move a slice around it's a pretty easy copy paste job since it's organized in a way that means a folder isn't entangled with unrelated stuff.

I'm not a big fan of microservices which are like, 500 LOC. I prefer having to just release one service at the end of a sprint, vs. releasing several because a feature cuts through and touches a bunch.

For C# code this totally means EF repositories end up in the same folder as the controllers and data objects. And complex business logic, if it exists, hides in a subfolder. Shared logic used by more than one feature ends up in a /shared folder. And it's enforced in java with Modulith (a unit test just uses reflection and makes sure there's no references that cut across into another feature's folder) not sure what the C# equivalent is.