Как управлять несколькими клиентами с немного отличающимися бизнес-правилами? [закрытый]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот кое-что, что поможет вам начать работу с многопользовательской архитектурой:

Multi-Tenant Data Architecture

SaaS шаблоны аренды баз данных