Есть система, которой пользуются несколько десятков организаций. Для подавляющего большинства эта система выглядит одинаково, но для некоторых отдельных организаций реализуются какие-то фичи, которые для других не включаются по каким-то причинам.
Вопрос в том, как правильно организовать и хранить это всё.
У нас кроме этого есть система features, где мы какой-то функционал тоже можем включать для определенных организаций, но это изначально использовалось для постепенного ввода в эксплуатацию каких-то новых фич. Включаем для тестовых организаций, проверяем, включаем для каких-то пилотных организаций, с которыми хороший контакт имеется, если всё хорошо, то включаем для всех, а механизм фичи убираем. Эта система сейчас работает через env-ы, где просто id организаций указываются.
Если вернуться к исходному вопросу, то самый простой вариант это просто в коде написать if (orgId == 1234) { ... }. Но это какая-то шляпа.
Второй простой вариант это использовать уже существующую систему features. Мне этот вариант не понравился с концептуальной точки зрения. Всё же эти фичи задумывались не для этого. Но в принципе не вижу ничего критичного в том, чтобы расширить эту систему и ввести понятие временного флага и постоянного флага.
Третий вариант это в базе в таблице organizations добавить поле вида can_use_some_feature. У всех организаций кроме одной в этом поле будет false. А в коде уже проверять это поле. Я склоняюсь к этому варианту, но коллеге он не нравится, хотя сам он не может предложить ничего лучше. Типа если будет 100 фич, то таблица будет из 100 полей (я не вижу в этом проблемы, да и 100 фич в ближайшее время не предвидится, но ему не нравится).
Разновидность третьего варианта это сделать таблицу features и отношение многие-ко-многим (ну или enum features, не суть). Тогда кучи полей не будет, но этот вариант уже мне кажется переусложненым на ровном месте.
