Как говорит Брайан, публикуя API, вы должны как можно больше его использовать, а это значит, что он должен меняться как можно меньше после первоначального выпуска. Однако, чтобы сделать что-то стабильное, нужно приложить немало усилий, поэтому, если вы не готовы использовать API, вам следует как можно больше его усвоить, и по этой причине вы можете захотеть объединить вещи, а не разделять их.
Однако я не собираюсь предлагать архитектуру, которая соответствует вашему приложению на основе описания из 5 параграфов. Что вам нужно сделать, так это взвесить плюсы и минусы нескольких крупных проектов, а не кучку слабо связанных небольших проектов. Я имею в виду, что чем больше вы планируете заранее, тем легче вам будет это делать, если вы будете придерживаться плана.
Итак, вопреки ответу Бриана, я бы не советовал вам делать всю вашу систему «настолько слабой, насколько это возможно», только чтобы вы делали ее настолько слабой, насколько это необходимо. ;) Слабосвязанный код может вызвать столько же проблем, сколько и тесно связанный, если вы злоупотребляете им.
См:
1. Что лучше, много маленьких сборок или одна большая сборка?
2. Конкретные недостатки многих-малых сборок?
В конце концов, только вы знаете, как сильно вы хотите сосредоточиться на каждой из «... способностей», удобстве обслуживания, расширяемости, надежности и т. Д. Так что определите свои приоритеты и цели и планируйте соответственно.
Что касается стратегий ветвления, вы можете прочитать Руководство по ветвлению TFS 2.0 , в котором есть хорошее представление о различных стратегиях ветвления - от базовых до продвинутых. Даже если вы не используете TFS, это хорошее руководство для чтения (сейчас я использую SVN). Поскольку в настоящее время я работаю в небольших командах с 1-4 разработчиками, я склонен использовать стратегию, которая находится между базовой и стандартной. Не то, чтобы я рекомендовал это для вас, но это лучше всего подходит для нашей команды.
Что касается обмена кодом между проектами. В SVN мы можем использовать « externals », что означает, что общий файл будет отображаться в нескольких папках, поэтому, когда вы изменяете одну копию и фиксируете изменение в svn, все остальные копии будут обновлены при следующем обновлении svn , Тем не менее, я не могу вспомнить, есть ли в TFS нечто подобное.
Примечание: Остерегайтесь внешних факторов в SVN ... они могут вызвать ... проблемы. ;)
Мой совет: постарайтесь не использовать как можно больше страниц aspx, ascx и master. Обычно болит гораздо больше, чем помогает. Вместо этого попробуйте использовать наследование или другие альтернативы для достижения вашей цели.
ASP.NET MVC 2.0 имеет концепцию под названием «Области», в которой вы строите подразделы приложения изолированно от остальных. Насколько я знаю, эти участки можно поддерживать в отдельных проектах от «основного» приложения. Это звучит очень похоже на то, что вы просите, так что, возможно, вам стоит посмотреть на это.
Надеюсь, это имеет смысл. ;)