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

Вопрос в том, как правильно организовать и хранить это всё.

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

Если вернуться к исходному вопросу, то самый простой вариант это просто в коде написать if (orgId == 1234) { ... }. Но это какая-то шляпа.

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

Третий вариант это в базе в таблице organizations добавить поле вида can_use_some_feature. У всех организаций кроме одной в этом поле будет false. А в коде уже проверять это поле. Я склоняюсь к этому варианту, но коллеге он не нравится, хотя сам он не может предложить ничего лучше. Типа если будет 100 фич, то таблица будет из 100 полей (я не вижу в этом проблемы, да и 100 фич в ближайшее время не предвидится, но ему не нравится).

Разновидность третьего варианта это сделать таблицу features и отношение многие-ко-многим (ну или enum features, не суть). Тогда кучи полей не будет, но этот вариант уже мне кажется переусложненым на ровном месте.

Как бы тут правильно поступить?

Здравствуйте, vsb, Вы писали:

vsb>У нас кроме этого есть система features, где мы какой-то функционал тоже можем включать для определенных организаций, но это изначально использовалось для постепенного ввода в эксплуатацию каких-то новых фич. Включаем для тестовых организаций, проверяем, включаем для каких-то пилотных организаций, с которыми хороший контакт имеется, если всё хорошо, то включаем для всех, а механизм фичи убираем. Эта система сейчас работает через env-ы, где просто id организаций указываются.

vsb>Разновидность третьего варианта это сделать таблицу features и отношение многие-ко-многим (ну или enum features, не суть). Тогда кучи полей не будет, но этот вариант уже мне кажется переусложненым на ровном месте.

Если на пальцах, то как в лицензировании:
Организация ==> [feature1, feature2...featureN]

Оформить это в виде отдельного манагера, который отвечает за включение фич.

Здравствуйте, vsb, Вы писали:

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

Фича — отдельно устанавливаемый модуль, модуль ставится — фича работает.

Здравствуйте, vsb, Вы писали:

vsb>Если вернуться к исходному вопросу, то самый простой вариант это просто в коде написать if (orgId == 1234) { ... }. Но это какая-то шляпа.
Надо исходить из требований. Если тут сейлзы такие счастливые "мы тут фичу 3541 впарили организации 1234!". А потом:

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

Решай сам.

vsb>Третий вариант это в базе в таблице organizations добавить поле вида can_use_some_feature.
vsb>Разновидность третьего варианта это сделать таблицу features и отношение многие-ко-многим
vsb>Как бы тут правильно поступить?
А механизм прав на операции в этой системе неужели не позволяет всё перечисленное?

Здравствуйте, Osaka, Вы писали:

vsb>>Третий вариант это в базе в таблице organizations добавить поле вида can_use_some_feature.
vsb>>Разновидность третьего варианта это сделать таблицу features и отношение многие-ко-многим
vsb>>Как бы тут правильно поступить?
O>А механизм прав на операции в этой системе неужели не позволяет всё перечисленное?

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

Здравствуйте, vsb, Вы писали:

vsb>Разновидность третьего варианта это сделать таблицу features и отношение многие-ко-многим (ну или enum features, не суть). Тогда кучи полей не будет, но этот вариант уже мне кажется переусложненым на ровном месте.

vsb>Как бы тут правильно поступить?

Это звучит как Feature Toggles. Но предположу, что одной базой вы не ограничитесь, для полноты должна быть поддержка на всех стадиях SDLC (включая тестирование на стендах). А в целом да: будут таблицы, переменные окружения, инджекты какие-то контроллеров фитчей (если уже дорого-богато делать).

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Здравствуйте, vsb, Вы писали:

Я бы опирался на следующие составляющие в вашем случае:

Надо ли динамически включать и выключать фичи? Если нет, то положить такое в статику.
На сколько много комбинаций: компания-{набор флагов}

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

Если идти дальше, то если у вас не С++, а C# или Java то можно повесить атрибуты аннотации и сделать это в виде АОП.

Здравствуйте, vsb, Вы писали:

vsb>Вопрос в том, как правильно организовать и хранить это всё.
По описанию похоже на классическую RBAC (Role-Based Access Control). Ролям соответствуют наборы permissions, которые и определяют доступность модулей.
Для дебага и бет используется просто отдельная роль со своими пермишнами.

Здравствуйте, vsb, Вы писали:

Поддержка плагинов/скриптов. Отдельный клиент — отдельный набор плагинов или внешних скриптов