Zorientowana na architekturę (strukturę) a struktura projektu zorientowana na cechy

Projekt, w który zaangażowałem się, ma strukturę plików / folderów zorientowaną na architekturę:

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

Jest to jasne z architektonicznego punktu widzenia systemu (zaproponowany przez zespół programistów).

Jest to struktura zorientowana na funkcje, zaproponowana przez zespół projektantów:

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

Ten wariant jest bliższy projektantom i jasno opisuje funkcję, którą należy wdrożyć.

Nasze zespoły rozpoczęły świętą wojnę: jakie jest najlepsze podejście. Czy ktoś mógłby nam pomóc i wyjaśnić wady i zalety pierwszego i drugiego. Może istnieje trzeci, który jest bardziej przydatny i korzystny dla nas obu.

Dziękuję Ci.

Głosowałbym na drugą. W pierwszej strukturze procedury obsługi zdarzeń dla FeatureAsą całkowicie niezwiązane z procedurami obsługi zdarzeń dla FeatureB. Wygląda na to, że programiści będą pracować nad jedną funkcją naraz, a jeśli pracujesz nad FeatureXżądaniem, jest o wiele bardziej prawdopodobne, że będziesz musiał zmodyfikować moduł FeatureXobsługi żądań niż, powiedzmy, FeatureZżądanie.

Nawiasem mówiąc, uwielbiam to, jak zadałeś to pytanie z neutralnego punktu widzenia.

Zawsze czułem się bardziej komfortowo z drugim podejściem, ale zawsze mam „funkcję” zwaną ogólną lub wspólną dla prawdziwie wspólnych / podstawowych klas.

Podejście drugie utrzymuje naprawdę osobne rzeczy oddzielnie, ale bez „wspólnego” obszaru czasami dzieli rzeczy na obszary, które nie pasują dobrze.

Dlaczego twórcom funkcji zależy na szczegółach implementacji? Jeśli jest to separacja stron argumentu, myślę, że odpowiedź jest jasna. Ludzie wymyślający pomysły / funkcje nie określają struktury plików potrzebnej przez implementatorów.

Jest to szczególnie ważne, gdy implementacja funkcji obejmuje wiele bibliotek DLL, plików exe, baz danych lub innych elementów oprogramowania.

Muszę zgodzić się z drugim podejściem, biorąc pod uwagę dwie opcje. Pierwszy wygląda jak amorficzna kropelka. Przynajmniej drugi ma jakiś kształt.

To naprawdę zależy od tego, jak duży jest projekt. Jeśli „funkcje” są duże, każda z nich potrzebuje osobnego wiadra.

Nie rozumiem używanej terminologii, ale i tak spróbuję odpowiedzieć, ponieważ obie struktury wydają się być niewłaściwym podejściem.

O ile nie masz tylko kilku funkcji, musisz pogrupować je w kategorie - i to nie wydaje się być pokrywane w żadnym projekcie (chyba że taki jest Node1, ale sugeruje „cały X projektu” w przeciwnym razie i zastanawiam się, czy to WTF - czy jest Node2?)

Mogę rozważyć coś takiego:

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

Albo to:

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

Ale obaj przyjmują założenia, które mogą być całkowicie nie na miejscu - jeśli możesz zaktualizować swoje pytanie o więcej szczegółów, mogę zmienić zdanie. :)