Организация решения для продукта

Question

У нас есть базовый продукт, который разрабатывается на заказ для каждого клиента, который расширяет и перезаписывает функциональность базы.

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

Мы используем унаследованные формы, чтобы переопределить базовую функциональность и на сегодняшний день все формы и классы объединены в одних и тех же проектах, т. Е. UI, Data, Business ...

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

1. Способы организации решения в соответствии с вышеуказанными требованиями, количество проектов в решении достаточно велико, и мы хотим уменьшить это, чтобы повысить производительность труда разработчиков, мы думаем о создании ссылок DLL библиотеки Framework вместо ссылок на проекты
2. Есть ли какие-то хитрости при сборке и развертывании, которые нам не хватает, в настоящее время у нас есть наполовину автоматизированный процесс сборки и выпуска
3. Каков наилучший способ управления версиями
4. Любые лучшие практики для разработки продукта

Answer 1

Я могу дать вам совет по вашему первому вопросу, а может быть, и к следующему: на вашем месте я бы выбрал базовое решение DLL, которое можно было бы легко администрировать и разрабатывать командой, а также различные решения для каждого последующего квеста. проект. Тем не менее, базовое решение должно быть разработано надлежащим образом, с особой тщательностью к одному принципу проектирования: принципу «открытый / закрытый» [1], чтобы дальнейшее развитие инфраструктуры не нарушало существующие реализации.

[1] http://en.wikipedia.org/wiki/Open/closed_principle

Answer 2

Лично я твердо верю, что высокомодульная архитектура прекрасно здесь подойдет: базовое приложение должно предоставлять базовые / общие сервисы, а все специфичные для клиента функциональные возможности должны быть реализованы в виде плагинов (например, MEF ). Отсюда несколько мыслей:

1. Я бы выбрал одно решение для основного приложения плюс дополнительное решение для каждого клиента.
2. Сборка в один шаг обязательна. Просто потратьте некоторое время на написание нескольких скриптов MSBuild: это окупится в десять раз.
3. См. Нумерация версий APR для вдохновения.
4. Слишком широкий вопрос.