Architecture(structure)-oriented vs. feature-oriented project structure

Question

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.

Answer 1

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.

Answer 2

I have always been more comfortable with the second approach, but I always have a "feature" called general or common for the truly shared/base classes.

Approach two keeps truly separate things separate, but without the "common" area it sometimes separates things into areas that they don't fit well.

Answer 3

Why do the feature-inventors care about the implementation details? If that is the separation between the sides of the argument, then I think the answer is clear. People inventing ideas/features do not determine the file structure that is needed by the implementers.

This is a particularly important issue when a feature's implementation spans multiple dlls, exes, databases, or other software pieces.

Answer 4

Have to agree with the second approach, given the two options. The first one just looks like an amorphous blob. At least the second one has some shape.

It really depends on how big the project is. If the "features" are large, they each need their own distinct bucket.

Answer 5

I don't understand the terminology you're using, but will try to answer anyway, since both structures seem to be the wrong approach.

Unless you've only got a handful of features, you need to group them into categories - and that doesn't appear to be catered for in either design (unless that's what Node1 is intended as, but the "all X of project" suggests otherwise, and makes me wonder WTF it is - is there a Node2?)

I might consider something like this:

Root
|____ Event Handlers
|   |____ Category A
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Category B
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|
|____ Events
|   |____ Category A
|   |    |___ Feature #1 Events
|   |    |___ Feature #2 Events
|   |    |___ Feature #3 Events
|   |
|   |____ Category B
|   |    |___ Feature #4 Events
|   |    |___ Feature #5 Events
|   |
|

Or this:

Root
|____ Category A
|   |____ Event Handlers
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Events
|        |___ Feature #1 Events
|        |___ Feature #2 Events
|        |___ Feature #3 Events
|   
|____ Category B
|   |____ Event Handlers
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|   |____ Events
|        |___ Feature #4 Events
|        |___ Feature #5 Events

But they're both making assumptions which may be completely off - if you can update your question with more details I may change my mind. :)