Как управлять несколькими клиентами с несколько разными бизнес-правилами?

Ответ 1

Я бы рекомендовал против поддерживать отдельные ветки кода для каждого клиента. Это кошмар, чтобы поддерживать рабочий код против вашего Core.

Я рекомендую вам реализовать шаблон стратегии и покрыть ваши "пользовательские настройки" автоматическими тестами (например, Unit и Functional) всякий раз, когда вы меняя ваш Core.

UPDATE:

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

Например, когда вы только что зарегистрировали клиента X (надеюсь, все через Интернет), их веб-сайт будет создан в течение XX минут и отправит клиенту электронное письмо, в котором он будет готов.

Вы определенно хотите настроить среду непрерывной интеграции (CI). TeamCity - отличный инструмент и бесплатный.

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

Bottom Line: После того, как вы охватите несколько клиентов, вам нужно начать думать о автоматизации своих операций и развертывании в качестве еще одного приложения для себя. p >

UPDATE: Этот post освещает негативные последствия ветвления на клиента.

Ответ 2

Это не то, что вы хотите решить с помощью управления исходным кодом, но в рамках архитектуры вашего приложения.

Я бы придумал какую-то плагиновую архитектуру. Какие плагины для использования, для которых веб-сайт станет проблемой конфигурации, а не проблемой управления версиями.

Это позволяет использовать ветки и т.д. для материала, для которого они предназначены: параллельная разработка кода между (или, может быть, даже более) релизами. Каждый плагин становится отдельным проектом (или подпроектом) в вашей системе исходного кода. Это также позволяет объединить все плагины и основное приложение в одно визуальное студийное решение, чтобы помочь в анализе зависимостей и т.д.

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

Ответ 3

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

Прежде всего, такие настройки будут стоить вам как в краткосрочной, так и долгосрочной перспективе. Если у вас есть контроль над этим, поместите некоторые сдержек и противовесов, чтобы продажи и маркетинг не слишком усердно продавали настройки.

Я согласен с другими плакатами, которые говорят НЕ использовать источник управления для управления этим. Он должен быть встроен в архитектуру проекта, где это возможно. Когда я впервые начал работать у своего нынешнего работодателя, для этого использовался источник контроля, и он быстро стал кошмаром.

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

Я бы сказал, что различия в бизнес-логике, вероятно, были наименее сложной частью опыта для нас (ваш пробег может варьироваться в зависимости от характера необходимых настроек). Для нас большинство вариаций в бизнес-логике можно разбить на набор значений конфигурации, которые мы храним в XML файле, который был изменен при развертывании (если задан машиной) или сохранен в конкретной папке клиента и хранится в исходном элементе управления (объясняется ниже). Бизнес-логика получает эти значения во время выполнения и соответствующим образом корректирует ее выполнение. Вы можете использовать это совместно с различными стратегиями и шаблонами factory, а также - поля конфигурации могут содержать имена стратегий и т.д..... Кроме того, модульное тестирование может использоваться для проверки того, что вы не нарушили работу других клиентов при внесении изменений. В настоящее время добавление большинства новых клиентов в систему включает простое смешивание/сопоставление соответствующих значений конфигурации (что касается бизнес-логики).

Больше проблем для нас является управление содержимым самого сайта, включая страницы/таблицы стилей/текстовые строки/изображения, все из которых наши клиенты часто хотят настроить. Текущий подход, который я предпринял для этого, - создать дерево папок для каждого клиента, который отражает основной сайт - это дерево коренится в папке с именем "custom", которая находится в папке основного сайта и развернута с сайтом. Содержимое, помещенное в набор папок, зависящих от клиента, либо переопределяет, либо сливается с содержимым по умолчанию (в зависимости от типа файла). Во время выполнения правильный файл выбирается на основе текущего контекста (пользователя, языка и т.д.). Таким образом, сайт может обслуживать несколько клиентов. Эффективность также может вызывать беспокойство - вы можете использовать кеширование и т.д., Чтобы сделать это быстрее (я использую собственный VirtualPathProvider). Самая большая проблема, с которой мы сталкиваемся, - это бремя визуального тестирования всех этих страниц, когда нам нужно внести изменения. В принципе, чтобы быть на 100% уверенным, что вы не нарушили что-то в пользовательской настройке клиента, когда вы изменили общую таблицу стилей, изображение и т.д., Вам придется визуально проверять каждую страницу после любого значительного изменения дизайна. Я разработал некоторое "чувство" со временем относительно того, какие изменения могут быть выполнены комфортно, не нарушая ничего, но он по-прежнему не является надежной системой любыми средствами.

В моем случае я также не имею никакого контроля, кроме предложения моего мнения о том, какие визуальные/кодовые настройки проданы настолько МНОГИЕ из них, чем я хотел бы, чтобы они были проданы и реализованы.

Ответ 4

Как упоминалось ранее, управление источником не кажется хорошим решением для вашей проблемы. Мне кажется, что лучше иметь одну базу кода, используя архитектуру с несколькими арендаторами. Таким образом, вы получаете много преимуществ с точки зрения управления своим приложением, загрузки службы, масштабируемости и т.д.

Наш продукт, использующий этот подход и то, что у нас есть, - это некоторые (основные) функциональные возможности, одинаковые для всех клиентов, пользовательские модули, которые используются одним или несколькими клиентами, а в основе "настройка" - простой механизм документооборота, который использует разные рабочие процессы для разных клиентов, поэтому каждый клиент получает основные функции, свои собственные рабочие процессы и некоторые расширенные модули, которые либо специфичны для клиента, либо обобщены для большего количества одного клиента.

Здесь вы можете начать с многопользовательской архитектуры:

Архитектура данных с несколькими арендаторами

Ответ 5

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

• Если вы можете сохранить центральную конфигурацию, определяющую уникальность от клиента к клиенту
• Если вы можете централизовать бизнес-правила для одного класса или группы классов
• Если вы можете сохранить бизнес-правила в базе данных и вытащить на основе клиента
• Если бизнес-правила могут быть основаны на DB/SQL (каждый клиент имеет свой собственный DB

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

Ответ 6

Слой приложения. Один из этих слоев содержит настройки и должен быть выведен в любое время без влияния на остальную часть системы. Очень полезны "триггеры на уровне приложений и DB" (цитируемые, поскольку они могут или многие не используют фактические триггеры БД), которые вызывают код, специфичный для клиента, или параметризированы с помощью ключей клиента).

Ядро никогда не следует настраивать, но вы должны сложить его где-нибудь, даже если это упрощенная веб-фильтрация.

Ответ 7

У нас есть базовая база данных, которая имеет функциональные возможности, которые получают все клиенты. Затем каждый клиент имеет отдельную базу данных, содержащую настройки для этого клиента. Это дорого стоит с точки зрения обслуживания. Другая проблема заключается в том, что, когда два клиента запрашивают уникальную функциональность, она часто выполняется раздельно двумя отдельными командами. В настоящее время мало сделано для того, чтобы делиться custiomization между клиентами и сделать обычные входящие в основное приложение. Каждый клиент имеет свой собственный портал приложений, поэтому мы не беспокоимся об изменении одного клиента, затрагивающего другого клиента.

Сейчас мы смотрим на переход к процессу с помощью механизма правил, но есть некоторая озабоченность тем, что производительности не будет, чтобы количество записей, которые нам нужно обрабатывать. Однако в ваших обстоятельствах это может быть жизнеспособной альтернативой.

Ответ 8

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

• Веб-страницы были настраиваемыми - мы могли бы перетаскивать поля из поля зрения, размещать их там, где мы хотели, с собственным именем для метки поля.
• Добавьте наши собственные представления или хранимые процедуры и используйте их в: сетях данных (вместе с обновлением proc) и отчетах. Каждому клиенту будет нужна собственная база данных.
• Пользовательское сопоставление файлов Excel для импорта данных в систему.
• Добавьте наши собственные вычисленные поля.
• Возможность запуска пользовательских скриптов в формах во время различных событий.
• Определите собственные поля.

Если клиенты - крупные компании, вам почти понадобятся ваши собственные SDK, API и т.д.

Ответ 9

Другим большим ресурсом является сериал Ayende, который вы ищете в своем блоге для многопользовательской аренды.