Например, если я использую какую-то MVC-подобную архитектуру, какую структуру папок мне следует использовать:
domain1/
controller
model
view
domain2/
controller
model
view
Или:
controllers/
domain1
domain2
models/
domain1
domain2
views/
domain1
domain2
Я намеренно пропустил расширения файлов, чтобы этот вопрос не зависел от языка.
Лично я предпочел бы разделить по бизнес-доменам (интуитивное чувство), но я вижу, что большинство / много фреймворков разделены по техническим областям. Почему я должен выбрать один над другим?
architecture
Флориан Маргейн
источник
источник
Ответы:
Я думаю, что это зависит от конкретного проекта.
Например, если разные бизнес-домены полностью независимы друг от друга, я бы организовал их по бизнес-доменам.
Но если между бизнес-доменами существует общий код, или, скорее, бизнес-домены - это разные варианты одной и той же кодовой базы, то представляется логичным организовать их по техническим областям . И если вы используете какой-либо объектно-ориентированный язык, то, вероятно, вы можете создать подклассы ваших общих контроллеров, моделей и т. Д. В своих бизнес-файлах, чтобы сделать их тоньше.
Существует также (золотая) середина между ними - раздели общий код в его собственный домен и используй его в других доменах. Это дает вам интуитивно понятное расположение, но позволяет использовать общий код для бизнес-доменов.
PS. Я думаю, что большинство фреймворков организовано по техническим областям только потому, что они ожидают, что вы объединяете разные бизнес-домены в один проект, только если у вас есть общий код, и в противном случае вы создадите отдельные проекты.
РЕДАКТИРОВАТЬ:
Например, предположим, что есть веб-приложение, которое обрабатывает склад компании. В общей форме это может относиться ко многим компаниям, но у каждой из них могут быть некоторые особенности, которые не встречаются и запрещают их покупать. Например, один из них развернул планшеты на вилочные погрузчики и нуждается в специальном представлении для них, в то время как другой хочет организовать элементы в три уровня вместо по умолчанию двух.
Конечно, вы можете раскошелиться на проект для каждой из этих компаний. Но если структура / язык позволяет, вы можете использовать подклассы или плагины и т. Д., Чтобы настроить отдельные части общего проекта в соответствии с потребностями каждого клиента и организовать их в макетах Business Domain.
Например, если общий проект экспортирует в JSON только сам элемент, Domain1 может создать подкласс контроллера и заставить его экспортировать также недавние проблемы с доставкой.
И если позже вы обнаружите, что Domain1 имеет компонент, который также подходит для Domain2, вы можете извлечь его общую версию в Shared.
Как вы сказали, многие фреймворки организованы по техническим областям, и это то, что я использовал на данный момент, просто потому, что мой выбор FW делает это проще. Но с небольшим (или большим) количеством консистентной смазки, я думаю, я мог бы также переписать пути включения для поддержки макета Business Domain.
источник
Я думаю, что очень интересно спросить: «Что я могу добавить на регулярной основе, больше доменов или больше технических разделов?» Тогда, каков бы ни был ответ, поместите это на верхний уровень.
В большинстве случаев ваша техническая архитектура будет укрепляться быстрее, чем ваш домен. Это означает, что вы должны организовать сначала по домену, а затем по архитектурному компоненту. Причина в том, что когда что-то в домене изменяется, вам, возможно, придется добавить или изменить несколько технических компонентов в этом домене, но, надеюсь, это локализовано и не сильно распространится на другие домены.
Если вы изменили свою структуру GUI, то это означает, что ваши изменения будут распространяться на все приложение, но опять же, вы редко меняете свою среду GUI, но вы всегда меняете логику вашего домена.
Держите вещи вместе, если они могут измениться одновременно.
источник
Существует еще одна альтернатива, которая заключается в перемещении отдельных частей в плагинах. CakePHP делает это, например. Это позволит вам создавать полные части MVC, которые можно повторно использовать, и которые вы можете отсортировать по любой логике.
Ваше основное приложение будет просто использовать их и ссылаться на них.
В основном ваш вопрос также о сплоченности и сцеплении. Вы хотите, чтобы отдельные части работали максимально независимо. Таким образом, вы получаете тестируемый и повторно используемый код.
Принимая это во внимание: если бы вы разделились по доменам, как бы вы повторно использовали части своего приложения? Например, возьмем интернет-магазин: поступает запрос для / orders / view / 1, поэтому вам нужно показать номер заказа. 1. Переходит к / orders / controllers / order_controller. Если вы разделили домен по продуктам и заказам, вам уже потребуются части другого «домена».
Там вы можете начать взаимодействовать, но, скорее всего, в большинстве случаев они слишком сплоченные. Если вы принимаете технический подход. Например, у вас может быть плагин для обработки заказов. Вы помещаете в него объекты Product из своего центрального приложения. Таким образом, вы можете легко протестировать плагин, просто создайте объект Product с именем и ценой и отправьте его.
Плагин будет делать именно то, что ему нужно. Это будет зависеть от его ввода, а не от других «частей / доменов / областей».
источник
Microsoft ASP.Net MVC 3 имеет понятие «Области». Когда вы вводите «Области» в свой проект MVC, они разбивают его следующим образом:
Я нашел это вполне естественным. Область - это «большой кусок» проекта, и работа в автономном блоке просто имеет большой смысл.
Мы использовали пространства имен, чтобы соответствовать, FWIW.
источник
Из моего личного опыта работы с интернет-магазином, состоящим из 300 000 строк кода, я всегда выбирал организацию по бизнес-доменам. Таким образом, вы можете не только получить краткий обзор всех соответствующих классов, когда работаете над одной функциональной областью, в Java вы также можете использовать видимость пакета.
Некоторые детали для тех, кто заинтересован: Когда проект был запущен 5 лет назад, разработчики создали следующую структуру пакета:
Каждая функция магазина, такая как корзина покупок, поиск товара и т. Д., Состоит из нескольких действий, каждое из которых имеет свой собственный класс формы (структура, предписанная платформой MVC). В результате мы получили более 200 классов в пакете действий, каждый из которых полностью отделен от связанного с ними класса формы. Что еще хуже, действия не реализуют слишком много логики, а вызывают специфичные для функции сервисы, которые находятся в еще одном пакете.
Я предложил и убедил команду, что мы должны перейти к организации пакетов по бизнес-доменам. Аргументация проста: если вы действительно хотите увидеть список всех действий, вы можете просто открыть представление иерархии типов любой достойной IDE. Однако то, что IDE не может сделать, это вывести бизнес-домен, к которому принадлежит класс. Кроме того, этот подход позволяет вам делать общедоступными только те классы, которые необходимы для некоторых функций, оставляя остальное на видимости пакета.
источник
Я согласен, что многие фреймворки разделены по техническим областям, и поэтому я часто начинаю этот путь при использовании новой фреймворк. Однако я последовательно выбираю использование бизнес-домена в качестве основного уровня организации папок.
Лично я думаю, что гораздо проще хранить мой Foo Controller и Foo Repository или что-либо еще вместе, чем переходить назад и вперед между папкой Controller и папкой Repository, так как мне часто приходится работать над обоими при добавлении функций вокруг Foo. В более крупных проектах это еще более важно, поскольку расстояние между техническими папками может быть значительным и стать заметной тратой времени при разработке.
источник