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

Question

Проект, который я задействовал, имеет архитектуру файлов / папок проекта:

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

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

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

Спасибо.

Answer 1

Я бы выбрал второй вариант, чтобы обеспечить долговечность приложения.

Позвольте мне объяснить это на примере:

Однажды, через год после выпуска приложения и спустя месяцы после того, как команда, которая создала исходный код, ушла, пользователь обнаруживает и сообщает об ошибке в определенном процессе. Билет, безусловно, будет выглядеть примерно так: «Этот материал не работает», который после некоторого пинг-понга по электронной почте будет выглядеть как «Я не могу сохранить заказ на несколько продуктов для австралийского клиента».

Что касается первой структуры проекта, вам необходимо выполнить поиск среди всех обработчиков запросов и событий вашего проекта, в которых содержится ошибочный код. Во втором случае вы можете сузить область поиска в модуле сохранения заказов (или, в зависимости от степени детализации структуры, в модуле «Сохранение заказов за рубежом / в нескольких странах»).

Это может сэкономить много времени и облегчить маневренность IMO.