Well to be clear, this was not supposed to be a jab at gitflow, or me complaining specifically about gitflow. I merely used “gitflow” as an example of a set of conventions and standardizations that comes nicely packaged as one big set of conventions.
But there’s nothing wrong with gitflow. I was just saying - it are not set in stone rules you must follow religiously. If you’re using it and it seems more practical to adapt the flow for your own use-case, don’t worry it’d be considered wrong to not stick strictly to it
I’m not completely sure which classes you’re talking about - but it sounds like the Business Process Layer
“Controllers” (in dotnet at least) is usually reserved for the class that initially intakes the http request after middleware (auth, modelbinding etc)
It’s probably easier with a concrete example, so lets say the action is “Create User”
It depends on the rest of your architecture, but I usually start with a
UserController
- that takes all user related requests.To make sure the Controller doesn’t get super big with logic, it sends it though mediatr to a
CreateUserCommandHandler
But it’s a big vague which parts you’re asking about…
Everything else you’ve described
Is “cross-cutting”, “Data Access Layer”, and “Service Agent Layer” maybe a bit “Anti-corruption Layer” - but there’s a lot of other things in between that “do the needful”