Есть задача на реализацию проекта на MVC. Проект будет состоять из множества модулей(20-40 штук).
Каждый бизнес модуль представляет собой некую систему, к примеру модуль заявок, модуль мероприятий и т.д.
Для удобства работы с модулем планируется организовать его так, чтобы вся работы велась в нем. В каждом модуле сделать структуру примерно такую. Один модуль - 1 dll. Слои разделены неймспейсами.

Соответственно получаем четкую структуру всего проекта, сразу понятно что где лежит и не бегаем по модулям. Соответственно, контроллеры и вьюМодели там.
Проект Web не имеет контроллеров и вьюМоделей.
Проект Core.Library хранит общий функционал, расширения и т.д.
Еще планируется проект для админки.

0. Есть мысли роуты, относящиеся к модулю, так же в проект модуль закинуть. Заполнение таблицы роутов будет в проекте Web, будем тянуть через рефлексию.
1. На сколько такая организация приемлема?
2. Как в больших проектах организовывают структуру солюшена?

Подскажите, как видится вам правильнее.

hVosttSliva,

Разделить можно следующим образом для монолита:

1. Инфраструктурные сборки (DI, кеш, лог, блокировки, безопасность, и проч.)
2. Сборки доступа к данным (DAL, Repo...)
3. Бизнес-логика (при чём не важно сколько логических модулей, это на кол-во сборок не отражается напрямую, можно не париться и засунуть всё в одну DLL, и разделять по мере острой необходимости)
4. Компоненты для построения UI (dll, npm..)
5. Собственно единственное веб-приложение, которое содержит UI, соединяет всё добро в кучу и содержит только прикладной код. Прикладной код представляет собой набор действий контроллеров, разделённый по Area, которые выражают логическое разделение (бизнес-модули), действия контроллеров содержат код вызова бизнес-логики, используют во вью компоненты для размещения функционала, и связывает данные отправляемые/полученные с клиента с логикой (view model, binding, validation...)



Да, все "модули" будут работать с одной БД. И тут конфиг EF с подключенными DbSet со временем будет длиною в километр.

hVosttодин единственный проект и «модули» засунуть в Area.

1. Какие плюсы Area в отличие от разделения Неймспейсами?
2. По большому счету не имеет значения выносить bll, dal в длл или разделять их неймспейсами.
Проект на старте и планируется активно развиваться, хочется на старте сделать внятную архитектуру.

Petro123SlivaКак в больших проектах организовывают структуру солюшена? сколько у вас страниц в приложении и табличек в базе?
Это выясняется до архитектуры. Чтобы не перепутать слово "большой")).

Пока не много, 20-30. Но у руководства большие планы. И хотелось бы на понять как он будет жить когда в нем будет 100-300 сущностей, которые работают с Entity Framework. Гоняя между слоями DTO.

hVostt
Под словом внятная должны быть какие-то обоснования выбранным решениям.
Разделяй и властвуй, это хороший принцип, но если делаете монолит, то как раз таки хорошо, когда фрагментации меньше, чем больше.

Под внятностью понимается, что при значительном расширении проекта сложность разработки не увеличивалась, ну или не значительно.
"но если делаете монолит". Монолит-телодвижений меньше, но с опаской смотрю на это через 1-3 года. Во что он вырастит....

hVostt,

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

Petro123А когда будет 500 таблиц, по любому перепишешь всё т.к. первый проект все переписывают)
не первый проект. Но все проекты не имели неопределенности в плане развития и масштабирования. Были четкие ТЗ, с конечной точкой разработки. А тут бесконечная разработка все нового и нового функционала. Чтобы не было через 2-3 года куча чего то непонятного.