The project, I have involved, has an architecture-oriented project's file/folder structure:Root|____ Node1    |____ Event Handlers    |         |___ <all event handlers of project>    |____ Events    |         |___ <all events of project>    |____ Request Handlers      |         |___ <all request handlers of project>    |____ Requests    |         |___ <all requests of project>    |____ ...It is a clear from the architectural point of view of system (has been proposed by development team).It is a feature-oriented structure has been proposed by designer team:Root|____ Feature #1    |____ Event Handlers    |         |___ <all event handlers of Feature #1>    |____ Events    |         |___ <all events of Feature #1>    |____ Request Handlers      |         |___ <all request handlers of Feature #1>    |____ Requests    |         |___ <all requests of Feature #1>    |____ ...This variant is closer to designers and it describes clearly a feature to be implemented.Our teams have started a holy war: what is the best approach. Could somebody help us and explain cons and pros of the first and second ones. Maybe there is a third one that is more useful and beneficial for both of us.Thank you.
Architecture(structure)-oriented vs. feature-oriented project structure
project structure
I would vote for the second one. In the first structure, event handlers for FeatureA are completely unrelated to event handlers for FeatureB. It seems that developers will be working on one feature at a time, and if you're working on a FeatureX request, it's far more likely that you'll need to tweak a FeatureX request handler than, say, a FeatureZ request.By the way, I love how you asked this question from a neutral point of view.