Здравствуйте, Константин Л., Вы писали:

КЛ>сколько систем ты так сделал и сколько у них юзеров и ролей?
Ну, я участвовал в системах, где у одной "инсталляции" до 1.5 миллиона пользователей. Типичный размер — около 100к.
Ролей — в пределах нескольких десятков. Это прямо максимум-максимум.
Не сказать, чтобы прямо "я сделал" — но наблюдал и участвовал в процессе проектирования изнутри компании.

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

TG>А зачем сравнивать ядро линукса и современные бизнес-приложения (вернее бизнес-сервисы)? У них же разная, скажем так, архитектурная топология. Бизнес-сервисы это уже распределенные системы как минимум по причине наличия БД.

Где я сравнивал? Я привел пример, что сложная система в виде монолита может существовать и хорошо управляться. Пример хорош тем, что все открыто и изучаемо.

Если у тебя есть поинт, что оно может существовать только потому, что там нет БД или "распределения", то раскрой тему. И тут бы уточнить, что ты имеешь в виду, уж распределеннее линуксов что-то придумать крайне сложно.

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

G>>Много причин использования МСА, далеко не все они оправданы с точки зрения экономики.
Z>Я могу назвать только одну — борьба со сложностью, но, имхо, это фикция. На уровне конечного продукта сложность возрастает. Иногда мне кажется, что на это всем пофиг, главное работой обеспечены.

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

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

G>Простите, не видел чтобы внедрение МСА сложность уменьшало. Сложность системы обычно кратно возрастает после такого, а небольшой бонус в виде независимого деплоя и ускорения сборки отдельных компонент зачастую не сможет перекрыть увеличение сложности системы и проблем для конечных пользователей

Конечно прощу, я тоже не видел. Зато видел, как этим успешно мотивировали выбор МСА, ведь монолит сложно поддерживать.

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


S>>Ну вот так и не выносим. Оракл является подробностью реализации этого "питонячьего сервиса" и ниоткуда больше не виден. Впрочем, это может быть и не оракл — "питонячьему сервису" с запасом может хватить sqlite.
·>Он виден с т.з. анализа безопасности.

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

Что передаете в БД в качестве субьекта авторизации? id юзера? Набор ролей? Есть ли роли, которые действуют на определенные сущности (например в этой организации юзер админ, а в этой простой гость)?

На каком языке пишете код правил доступа, сколько страниц текста он занимает, как его храните, ревьюите, тестируете, разворачиваете?

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

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

S>>>Ну вот так и не выносим. Оракл является подробностью реализации этого "питонячьего сервиса" и ниоткуда больше не виден. Впрочем, это может быть и не оракл — "питонячьему сервису" с запасом может хватить sqlite.
Z>·>Он виден с т.з. анализа безопасности.
Z>Коллега, я немного запутался в вашей дискуссии, подскажи, я не ошибся, ты действительно топишь за обеспечение секьюрити данных на уровне БД?
Если в том смысле, что используются средства БД типа как встроенные механизмы row level security, аккаунты в самой бд, вьюшки и т.п. (о чём писал Sinclair) — то нет.

Z>Что передаете в БД в качестве субьекта авторизации? id юзера? Набор ролей? Есть ли роли, которые действуют на определенные сущности (например в этой организации юзер админ, а в этой простой гость)?
В бд формируются запросы в зависимости от пермиссий... Т.е. это просто ещё как бы один критерий поиска, как тут Константин Л писал.

Z>На каком языке пишете код правил доступа, сколько страниц текста он занимает, как его храните, ревьюите, тестируете, разворачиваете?
На оснвном ЯП, обычно java, как и любой другой код.

Z>Как поступаете, если в какое-то поле юзер может писать только если это конкретный бизнес процесс со своими правилами, предусловиями и постусловиями? К примеру храним стейт из развесистой стейт-машины и от этого стейта зависит очень многое в плане можем писать/не можем писать. Как например будет выглядеть правило "посты редактируются редактором и корректором, никто, кроме суперадмина не может удалять ссылки и фотографии из опубликованного поста, заархивированный пост нельзя увидеть в ленте никому, но в админке его видят все сотрудники и суперадмин может его вернуть в ленту"?
Это же несколько независимых правил.
Отдельно есть пермиссии "редактирование поста", "удаление ссылок", "удаление фот", "просмотр архива" и т.п. И отдельно роли: "редактор", "корректор", "админ", "суперадмин"... и маппинг — что какая роль может.

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

·>Если в том смысле, что используются средства БД типа как встроенные механизмы row level security, аккаунты в самой бд, вьюшки и т.п. (о чём писал Sinclair) — то нет

Ок. На языке высокого уровня это примерно понятно как решается.