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

14

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.

project-structure

— Zzz
fuente

No entiendo ninguna estructura: ¿cuál es la diferencia entre eventos y solicitudes (y, por lo tanto, controladores de eventos y controladores de solicitudes)?

— Peter Boughton

1

Pregunta muy clara, ¡y neutral también!

— Michael K

1

Desde la perspectiva de la escalabilidad, el segundo enfoque debería ser bastante fácil de escalar horizontalmente.

— CodeART

11

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.

— Nota para uno mismo - piense en un nombre
fuente

1

+1 con una advertencia: para proyectos pequeños, el segundo dará como resultado una estructura de archivos más grande que la que hay en los archivos. Yo usaría el primero para esos.

— Michael K

@Michael estoy de acuerdo, pero en este caso es un gran proyecto.

— Zzz

1

+1: Y si alguna vez tiene que conversar con un usuario / cliente, entonces la terminología puede ser bastante consistente.

— Steven Evers

4

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.

— Cuenta
fuente

+1 para común y general (cada proyecto tiene utilidades generales, herramientas ...)

— Zzz

3

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

— John Fisher
fuente

1

Pensé en eso, pero, en igualdad de condiciones, el segundo enfoque tiene algunas ventajas filosóficas claras para todas las aplicaciones menos las más triviales. Por lo menos, es una buena sugerencia.

— Robert Harvey

@Robert Harvey: Si estás hablando de la organización ideal del proyecto, entonces tendría que pensar una nueva respuesta. Sin embargo, parece que están hablando de archivos que contienen código ...

— John Fisher

La clave es la separación de las características en cubos distintos. Para todas las aplicaciones, excepto las más pequeñas, necesitará algún tipo de organización como esta, ya sea que se refiera a una estructura de carpetas, una estructura de clases o una convención de espacio de nombres.

— Robert Harvey

1

@Robert Harvey: ¿Qué pasa con los problemas de compilación y despliegue? ¿Qué tal cosas más simples como simplemente poder usar un IDE para escribir y depurar el código? Algunas de estas cosas deberían tener un impacto poderoso en las estructuras de carpetas.

— John Fisher

1

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.

— Robert Harvey
fuente

1

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. :)

— Peter Boughton
fuente