Arquitectura del proyecto (estructura) orientada frente a estructura orientada a características

12

El proyecto, en el que he participado, tiene una estructura de archivos / carpetas 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 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ñadores:

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 que se implementará.

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

Gracias.

    
pregunta Zzz 10.11.2010 - 20:04

5 respuestas

11

Yo votaría por el segundo. En la primera estructura, los controladores de eventos para FeatureA no están relacionados con los controladores de eventos para FeatureB . Parece que los desarrolladores estarán trabajando en una característica a la vez, y si estás trabajando en una solicitud FeatureX , es mucho más probable que tengas que ajustar un controlador de solicitud FeatureX que, por ejemplo, un FeatureZ request.

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

    
respondido por el Note to self - think of a name 10.11.2010 - 20:13
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 realmente separadas por separado, pero sin el área "común" a veces separa las cosas en áreas que no encajan bien.

    
respondido por el Bill 10.11.2010 - 20:15
3

¿Por qué a los inventores de características les importan los detalles de la 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 problema particularmente importante cuando la implementación de una función abarca varias dlls, exes, bases de datos u otras piezas de software.

    
respondido por el John Fisher 10.11.2010 - 20:15
1

Deben estar de acuerdo con el segundo enfoque, dadas las dos opciones. El primero solo se ve como una burbuja 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 de ellas necesita su propio grupo distinto.

    
respondido por el Robert Harvey 10.11.2010 - 20:16
1

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

A menos que solo tenga un puñado de funciones, debe agruparlas en categorías, y eso no parece estar incluido en ninguno de los diseños (a menos que se pretenda que sea Node1, pero la "todas las X de el proyecto "sugiere lo contrario, y me hace pensar que 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. :)

    
respondido por el Peter Boughton 10.11.2010 - 21:29

Lea otras preguntas en las etiquetas