Architecture (structure) orientée par rapport à une structure de projet orientée fonctionnalités

Le projet, j'ai participé, a une structure de fichiers / dossiers de projet orientée architecture:

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

C'est clair du point de vue architectural du système (a été proposé par l'équipe de développement).

C'est une structure orientée fonctionnalités qui a été proposée par l'équipe de designers:

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

Cette variante est plus proche des concepteurs et elle décrit clairement une fonctionnalité à mettre en œuvre.

Nos équipes ont entamé une guerre sainte: quelle est la meilleure approche. Quelqu'un pourrait-il nous aider et expliquer les inconvénients et les avantages des premier et deuxième. Il y en a peut-être un troisième qui est plus utile et bénéfique pour nous deux.

Je vous remercie.

Je voterais pour le deuxième. Dans la première structure, les gestionnaires d'événements pour FeatureAsont totalement indépendants des gestionnaires d'événements pour FeatureB. Il semble que les développeurs travailleront sur une fonctionnalité à la fois, et si vous travaillez sur une FeatureXdemande, il est beaucoup plus probable que vous ayez besoin de modifier un FeatureXgestionnaire de demande que, disons, une FeatureZdemande.

Soit dit en passant, j'adore la façon dont vous avez posé cette question d'un point de vue neutre.

J'ai toujours été plus à l'aise avec la deuxième approche, mais j'ai toujours une "fonctionnalité" appelée générale ou commune pour les classes vraiment partagées / de base.

La deuxième approche permet de séparer les choses véritablement séparées, mais sans la zone «commune», elle sépare parfois les choses en zones qui ne correspondent pas bien.

Pourquoi les inventeurs de fonctionnalités se soucient-ils des détails de mise en œuvre? S'il s'agit de la séparation entre les côtés de l'argument, je pense que la réponse est claire. Les personnes qui inventent des idées / fonctionnalités ne déterminent pas la structure de fichiers dont les implémenteurs ont besoin.

Il s'agit d'un problème particulièrement important lorsque l'implémentation d'une fonctionnalité s'étend sur plusieurs DLL, exes, bases de données ou autres logiciels.

Je dois être d'accord avec la deuxième approche, compte tenu des deux options. Le premier ressemble à une goutte amorphe. Au moins le second a une forme.

Cela dépend vraiment de la taille du projet. Si les «fonctionnalités» sont grandes, elles ont chacune besoin de leur propre compartiment distinct.

Je ne comprends pas la terminologie que vous utilisez, mais j'essaierai de répondre de toute façon, car les deux structures semblent être la mauvaise approche.

À moins que vous n'ayez qu'une poignée de fonctionnalités, vous devez les regrouper en catégories - et cela ne semble pas être pris en charge dans les deux conceptions (à moins que ce soit le but de Node1, mais le "tout X du projet" suggère sinon, et je me demande WTF c'est - y a-t-il un Node2?)

Je pourrais envisager quelque chose comme ça:

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

Ou ca:

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

Mais ils font tous deux des hypothèses qui peuvent être complètement fausses - si vous pouvez mettre à jour votre question avec plus de détails, je pourrai changer d'avis. :)