Estructura de proyecto orientada a la arquitectura (estructura) versus estructura orientada a características

El proyecto, he involucrado, tiene una estructura de archivo / carpeta de proyecto orientada a la arquitectura:

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>
    |____ ...

Es un claro desde el punto de vista arquitectónico del sistema (ha sido propuesto por el equipo de desarrollo).

Es una estructura orientada a características que ha sido propuesta por el equipo de diseño:

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>
    |____ ...

Esta variante está más cerca de los diseñadores y describe claramente una característica a implementar.

Nuestros equipos han comenzado una guerra santa: cuál es el mejor enfoque. ¿Podría alguien ayudarnos y explicarnos los inconvenientes y los pros del primero y segundo? Quizás haya un tercero que sea más útil y beneficioso para los dos.

Gracias.

Yo votaría por el segundo. En la primera estructura, los controladores de eventos no FeatureAtienen ninguna relación con los controladores de eventos FeatureB. Parece que los desarrolladores trabajarán en una característica a la vez, y si está trabajando en una FeatureXsolicitud, es mucho más probable que necesite ajustar un FeatureXcontrolador de solicitud que, por ejemplo, una FeatureZsolicitud.

Por cierto, me encanta cómo hiciste esta pregunta desde un punto de vista neutral.

Siempre me he sentido más cómodo con el segundo enfoque, pero siempre tengo una "característica" llamada general o común para las clases verdaderamente compartidas / base.

El enfoque dos mantiene las cosas verdaderamente separadas, pero sin el área "común" a veces separa las cosas en áreas que no encajan bien.

¿Por qué los inventores se preocupan por los detalles de implementación? Si esa es la separación entre los lados del argumento, entonces creo que la respuesta es clara. Las personas que inventan ideas / características no determinan la estructura de archivos que necesitan los implementadores.

Este es un tema particularmente importante cuando la implementación de una característica abarca múltiples dlls, exes, bases de datos u otras piezas de software.

Tiene que estar de acuerdo con el segundo enfoque, dadas las dos opciones. El primero se parece a una gota amorfa. Al menos el segundo tiene alguna forma.

Realmente depende de qué tan grande es el proyecto. Si las "características" son grandes, cada una necesita su propia cubeta distinta.

No entiendo la terminología que está utilizando, pero trataré de responder de todos modos, ya que ambas estructuras parecen ser el enfoque incorrecto.

A menos que solo tenga un puñado de características, debe agruparlas en categorías, y eso no parece ser atendido en ninguno de los diseños (a menos que eso sea lo que pretende el Nodo1, pero el "todo X del proyecto" sugiere de lo contrario, y me pregunto qué es WTF: ¿hay un Nodo2?)

Podría considerar algo como esto:

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
|   |
|

O esto:

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

Pero ambos están haciendo suposiciones que pueden estar completamente equivocadas: si puede actualizar su pregunta con más detalles, puedo cambiar de opinión. :)