2010-11-10 7 views
5

Das Projekt, das ich beteiligt haben, hat eine Architektur orientierte Projekt Datei/Ordner-Struktur:Architektur (Struktur) -orientierten vs. Feature-orientierten Projektstruktur

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 ist eine klare von der Architektur her Systemansicht (wurde vom Entwicklungsteam vorgeschlagen).

Es ist eine funktionsorientierte Struktur wurde von Designer-Team vorgeschlagen:

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

Diese Variante ist näher an Designer und beschreibt eindeutig eine Funktion implementiert werden.

Unsere Teams haben einen heiligen Krieg begonnen: Was ist der beste Ansatz? Könnte jemand uns helfen und erklären Nachteile und Pros der ersten und zweiten. Vielleicht gibt es eine dritte, die nützlicher und vorteilhafter für uns beide ist.

Vielen Dank.

+0

Vielleicht möchten Sie Ihre Tags noch einmal überdenken ... alles, was vernünftigerweise getaggt werden kann [holywar] ist per Definition ziemlich S & A, nicht wahr? – dmckee

Antwort

5

Ich würde die zweite Option wählen, um die Langlebigkeit einer Anwendung zu erhalten.

Lassen Sie es mich mit einem Beispiel erklären:

Eines Tag, ein Jahr nach der Anwendung Release und Monaten nach dem Team, das den ursprünglichen Code worte verlassen hat, ein Benutzer erkennt und einen Fehler in einem bestimmten Prozess berichtet . Das Ticket wird sicherlich etwas wie "Dieses Zeug funktioniert nicht" aussehen, was nach ein paar E-Mail-Ping-Pongs enden wird "Ich kann eine Multi-Produkt-Bestellung für einen australischen Kunden nicht speichern".

Nun, in der ersten Projektstruktur müssen Sie unter allen Projekt Request und Event Handlern suchen, wo der Buggy Code ist. Auf der zweiten Seite können Sie Ihre Suche auf das Modul zum Speichern von Bestellungen eingrenzen (oder abhängig von Ihrer Strukturgranularität, dem Modul "Übersee/Multiproduktbestellung").

Es kann eine Menge Zeit sparen und Maintainability IMO erleichtern.

+0

+1 macht es in diesem Fall Sinn. – garik