Какое архитектурное решение выбрать для ролей пользователей?
Доброго времени суток!
Пишу проект, внутригородской-маркетплейс
1) Внутренние роли компании - Администратор(1), Бухгалтер(2), Менеджер по логистике(3).
2) Роли поставщиков - Бизнесмен (тот кто продает свои услуги на маркетплейсе) (4)
Бизнесмен может создавать себе-подобные роли используя матрицу возможностей (permissions)
То есть в коде проверяются именно permissions для Бизнесмена.
3) Роли доставки - Курьер (5)
Может быть как создан компанией, так и Продавцом
4) Клиент (заказ, оплата товаров) (6)
Надеюсь достаточно понятно сгруппировал.
Так вот к сути. В моей голове сейчас возникла такая идея
Разнести вообще это все на 4 (ну или чуть компактней 3) разные таблицы, сделать 4 разных входа. (так как панели управление у ролей все-равно разные)
+Из плюсов
1) проще оперировать permissions внутри раздела Поставщиков.
2) Отделит Админов в отдельную группу.
3) Отделит Клиентов в отдельную группу (а значит любой поставщик по сути сможет иметь отдельный аккаунт клиента)
-Из минусов (это 4 разные таблицы)))
Хотелось бы услышать, это вообще адекватное решение в данной ситуации или лучше придерживаться стандартных практик и строить все полностью на permissions и их группировки в роли?
так как панели управление у ролей все-равно разные
изначальное утверждение не верное отсюда и вопрос. Еще раз - пройти почитать про RBAC, потом узнать что такое Identity Server, понять что аутентифицируются только люди, а не организации и перестать заниматься фигней.
Еще раз - все что написано в тексте вопроса - бесполезный поток мыслей не влияющий на результат
Ну и да, не надо путать Роли/Права и Сущности системы. Выбрать из списка Поставщиков и иметь права как у Поставщика это абсолютно не связанные задачи
Иван Шумов, Где я тут говорю про "выбрать из списка?"
Я говорю о том, что поставщик(бизнесмен) может создавать отдельные роли, с различными комбинациями возможностями(операциями), может создать кассира и эта роль должна быть привязана только к одному магазину(предприятию)
Есть глобальные роли, есть локальные(частные) роли.
Я говорю о том, что поставщик(бизнесмен) может создавать отдельные роли, с различными комбинациями возможностями(операциями), может создать кассира и эта роль должна быть привязана только к одному магазину(предприятию)
Любая здоровая система не имеет таких конфигураций. Максимальный пример если мы делаем как сервис - права как в Github или продукциях Atlassian. Причин на это много:
люди не умеют настраивать и мучаются
более низкий порог входа
(и не последнее по значимости) в любой доменной области роли давно выверены уже
Я видел миллион таких конфигураторов и со временем они почти все вымерли. Чем больше необходимость такого функционала тем меньше понимания у компании чем они занимаются и тем дороже им обходятся эти ошибки. Иметь отдельную админку для настройки ролей централизовано у владельцев сервиса это еще нормально, но давать это делать пользователям - дичь, печаль и содомия
Иван Шумов, Не будь это ТЗ и упрямым желанием продакта дать такую возможность, я бы не задавал этот вопрос и не ломал голову)
Я пытался переубедить примерно вашими же словами, но мне дают сокрушительные аргументы))
Иван Шумов, сокрушительные в данном случае сарказм)
Но из того, что говорят пользователи сервиса:
Бизнесмен сам заказывает через сервис, при этом бухгалтер сидит через этот же аккаунт и видит его заказы.
В некоторых заведениях, продавцы сами же и развозят товар, им не удобно переключаться между аккаунтами
Ну вот из устного разговора, вспомнил только это... Что хоть чуть-чуть поддавалось логике )
Но в общем, смотря на другие маркетплейсы, у них все сущности Владельцы сервиса, продавцы, водители, клиенты имеют отдельные входы и между собой ничем не связаны, поэтому и возникла идея про разделение на разные таблицы.
snchz, разноцелевые интерфейсы это нормально, могут быть хоть разные системы) это на само деле не важно. А вот описание действительно показывает что есть проблема и надо собирать обратную связь со всех пользователей чтобы лучше сформировать роли и права. Как уже писали стоит посмотреть в сторону BDD как минимум.
Про таблицы - тут будет скорее всего мало этого. При таких разных правах напрашивается SOA
Я бы выделил сущность User с привязанными к ней авторизацией и всякими там RBAC-ами. И отдельные сущности-профили для каждого типа (профиль клиента, поставщика, курьера и т. д.) с бизнес-логикой вокруг них.
Иван Шумов, Как считаете, есть ли "панацея" от этого всего...?
Делить сейчас на сервисы будет больно. Проект на самом деле не большой. Очень бы хотелось не выходить за рамки простого управления на основе ролей.
Я сейчас сомневаюсь в правильности дальнейших решений и поэтому, прошу оценить мое решение в данной ситуации.
Берем laravel
1) имеем сущность User. -на нее не навешиваем никаких RBAC (потому что это единичная роль клиента) используем стандартный провайдер авторизации в laravel
2) создаем сущность Supplier ( поставщик ) отделяем все свзянное с порталом поставщиков в отдельный домен. Создаем провайдер авторизации для поставщика. Накидываем RBAC.
3) Проделываем все тоже самое, что и для поставщиков для Driver(курьер) и Admin(Админстрация)
Разделяя на такие домены внутри монолита позволит при расширении возможностей той или иной роли в дальнейшем вынести ее в отдельный сервис.
Как считаете, есть ли "панацея" от этого всего...?
No silver bullet in this world
Делить сейчас на сервисы будет больно.
Я и не призываю, просто говорю как есть. Если что то стоимость разделения монолита на SOA/MSA растет экспоненциально с каждой внедренной фичой.
Очень бы хотелось не выходить за рамки простого управления на основе ролей.
Не хочется - не надо. Мы тут не можем указывать кому-то что делать и чего не делать.
Я сейчас сомневаюсь в правильности дальнейших решений
Правильно. Даже с учетом многолетнего опыта многие сомневаются. Для этого собирают критерии и строят сетку для принятия решений. Квадрат Декарта называется
прошу оценить мое решение в данной ситуации
Чтобы его грамотно оценить необходимо провести не менее месяца в тесном общении с вашим бизнесом и анализом текущего состояния проекта, а также квалификации всех вовлеченных людей к появлению данной фичи
Простой
