Архитектурно-ориентированная и функционально-ориентированная структура проекта

Проект, в котором я участвовал, имеет структуру файлов / папок ориентированного на архитектуру проекта:

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

Это ясно с архитектурной точки зрения системы (было предложено командой разработчиков).

Это функционально-ориентированная структура была предложена командой дизайнеров:

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

Этот вариант ближе к дизайнерам, и он четко описывает функцию, которая будет реализована.

Наши команды начали священную войну: какой подход лучше? Может ли кто-нибудь помочь нам и объяснить минусы и плюсы первого и второго. Может быть, есть третий, который более полезен и полезен для нас обоих.

Спасибо.

Я бы проголосовал за второй. В первой структуре обработчики событий for FeatureAсовершенно не связаны с обработчиками событий for FeatureB. Похоже, что разработчики будут работать над одной функцией за раз, и если вы работаете над FeatureXзапросом, гораздо более вероятно, что вам потребуется настроить FeatureXобработчик запроса, чем, скажем, FeatureZзапрос.

Кстати, мне нравится, как вы задали этот вопрос с нейтральной точки зрения.

Мне всегда было комфортнее со вторым подходом, но у меня всегда есть «особенность», называемая общей или общей для действительно общих / базовых классов.

Подход второй позволяет разделить действительно отдельные вещи, но без «общей» области он иногда разделяет вещи на области, которые им не подходят.

Почему изобретатели функций заботятся о деталях реализации? Если это разделение между сторонами аргумента, то я думаю, что ответ ясен. Люди, изобретающие идеи / функции, не определяют структуру файла, которая необходима разработчикам.

Это особенно важная проблема, когда реализация функции охватывает несколько dll, exe, баз данных или других частей программного обеспечения.

Приходится соглашаться со вторым подходом, учитывая два варианта. Первый просто выглядит как аморфный шарик. По крайней мере, второй имеет некоторую форму.

Это действительно зависит от того, насколько велик проект. Если «особенности» велики, каждый из них должен иметь свое отдельное ведро.

Я не понимаю терминологию, которую вы используете, но все равно постараюсь ответить, поскольку обе структуры кажутся неправильным подходом.

Если у вас есть только несколько функций, вам нужно сгруппировать их по категориям - и это не учитывается ни в одном из проектов (если только это не то, для чего предназначен Node1, но предлагает «весь X проекта») в противном случае и заставляет задуматься, WTF это - есть ли Node2?)

Я мог бы рассмотреть что-то вроде этого:

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

Или это:

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

Но они оба делают предположения, которые могут быть совершенно неверными - если вы можете обновить свой вопрос с более подробной информацией, я могу передумать. :)