Architektur (struktur) orientierte vs. merkmalorientierte Projektstruktur

14

Das Projekt, an dem ich beteiligt war, hat die Datei- / Ordnerstruktur eines architekturorientierten Projekts:

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 ein aus architektonischer Sicht klares System (wurde vom Entwicklerteam vorgeschlagen).

Es ist eine merkmalorientierte Struktur, die vom Designteam vorgeschlagen wurde:

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 den Designern und beschreibt deutlich ein zu implementierendes Merkmal.

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

Vielen Dank.

project-structure

— Zzz
quelle

Ich verstehe keine der beiden Strukturen - was ist der Unterschied zwischen Ereignissen und Anforderungen (und damit Ereignishandlern und Anforderungshandlern)?

— Peter Boughton

1

Sehr klare Frage - und auch neutral!

— Michael K

1

Aus der Perspektive der Skalierbarkeit sollte es relativ einfach sein, den zweiten Ansatz horizontal zu skalieren.

— CodeART

11

Ich würde für den zweiten stimmen. In der ersten Struktur haben Ereignishandler für FeatureAkeinerlei Beziehung zu Ereignishandlern für FeatureB. Es sieht so aus, als würden Entwickler jeweils an einer Funktion arbeiten. Wenn Sie an einer FeatureXAnfrage arbeiten, ist es weitaus wahrscheinlicher, dass Sie einen FeatureXRequest-Handler anpassen müssen, als beispielsweise eine FeatureZAnfrage.

Übrigens, ich finde es toll, wie Sie diese Frage aus neutraler Sicht gestellt haben.

— Notiz an mich selbst - denke an einen Namen
quelle

1

+1 mit einer Einschränkung: Bei kleinen Projekten führt die zweite zu einer größeren Dateistruktur als Dateien, in die sie eingefügt werden können. Ich würde die erste für diese verwenden.

— Michael K

@Michael ich stimme zu, aber in diesem Fall ist es ein großes Projekt.

— Zzz,

1

+1: Und wenn Sie sich jemals mit einem Benutzer / Kunden unterhalten müssen, kann die Terminologie ziemlich konsistent sein.

— Steven Evers

4

Ich war immer mit dem zweiten Ansatz zufriedener, aber ich habe immer ein "Feature", das als "allgemein" oder "allgemein" für die wirklich gemeinsam genutzten Klassen / Basisklassen bezeichnet wird.

Ansatz zwei trennt wirklich getrennte Dinge, aber ohne den "gemeinsamen" Bereich trennt er Dinge manchmal in Bereiche, die nicht gut passen.

— Rechnung
quelle

+1 für allgemeine und allgemeine (jedes Projekt hat allgemeine Dienstprogramme, Tools ...)

— Zzz

3

Warum interessieren sich die Feature-Erfinder für die Implementierungsdetails? Wenn das die Trennung zwischen den Seiten des Arguments ist, dann denke ich, ist die Antwort klar. Leute, die Ideen / Merkmale erfinden, bestimmen nicht die Dateistruktur, die von den Implementierern benötigt wird.

Dies ist besonders wichtig, wenn sich die Implementierung eines Features über mehrere DLLs, Exes, Datenbanken oder andere Softwareteile erstreckt.

— John Fisher
quelle

1

Ich habe darüber nachgedacht, aber wenn alle anderen Dinge gleich sind, hat der zweite Ansatz einige klare philosophische Vorteile für alle, außer für die trivialsten Anwendungen. Zumindest ist es ein guter Vorschlag.

— Robert Harvey

@Robert Harvey: Wenn Sie über die ideale Organisation des Projekts sprechen, dann müsste ich mir eine neue Antwort ausdenken. Es hört sich jedoch so an, als würden sie über Dateien sprechen, die Code enthalten ...

— John Fisher

Der Schlüssel ist die Aufteilung der Merkmale in verschiedene Bereiche. Mit Ausnahme der kleinsten Anwendungen benötigen Sie eine solche Organisation, unabhängig davon, ob Sie sich auf eine Ordnerstruktur, eine Klassenstruktur oder eine Namespace-Konvention beziehen.

— Robert Harvey

1

@ Robert Harvey: Was ist mit Build- und Bereitstellungsproblemen? Wie wäre es mit einfacheren Dingen wie der Möglichkeit, den Code mit einer IDE zu schreiben und zu debuggen? Einige dieser Dinge sollten einen starken Einfluss auf die Ordnerstrukturen haben.

— John Fisher

1

Muss mit dem zweiten Ansatz einverstanden sein, wenn man die beiden Optionen berücksichtigt. Der erste sieht aus wie ein amorpher Klecks. Zumindest der zweite hat eine gewisse Form.

Es kommt wirklich darauf an, wie groß das Projekt ist. Wenn die "Features" groß sind, benötigen sie jeweils einen eigenen Eimer.

— Robert Harvey
quelle

1

Ich verstehe die von Ihnen verwendete Terminologie nicht, werde aber trotzdem versuchen zu antworten, da beide Strukturen der falsche Ansatz zu sein scheinen.

Sofern Sie nicht nur eine Handvoll Features haben, müssen Sie diese in Kategorien gruppieren - und dies scheint in beiden Designs nicht berücksichtigt zu sein (es sei denn, Node1 ist dafür vorgesehen, aber das "All-X-of-Project" weist darauf hin ansonsten und ich frage mich, ob es WTF ist - gibt es einen Node2?)

Ich könnte so etwas in Betracht ziehen:

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

Oder dieses:

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

Aber beide treffen Annahmen, die möglicherweise völlig falsch sind - wenn Sie Ihre Frage mit weiteren Details aktualisieren können, kann ich meine Meinung ändern. :)

— Peter Boughton
quelle