Как я понял @GDXbsv Ваши предложения были сделать что-то подобное?

Нужно включать дополнительную логику чтобы эти свойства установить

Вот вам и пример качественных свойств

чёт мне нифига не стало ясно
как определилось вполне понятное свойство или не вполне?
выглядит как форлуп позволяет делать больше, чем мап
но при чём тут понятность?

В этом и проблема

Что числами не описываются эти вещи

Вполне понятное - то которое написано в контракте

Т.е. ты юзаешь мап особенно не усложняешь код, спамишь форлупами - усложняешь

Это похоже на связь табличек. Тут не видно связности вашего кода. Тоетсь например какое количество даных оно передает туда сюда и с какой целью. Например какие даные использует ваш Administration и какие Miting. Почему между нми дублируются данные.
Ну а так какие види каплинга вы тут видите и на сколько они большие

Как я понял цветные поля это контексты ваши. Я не вижу сейчас что изменится от того нарисованы они или нет есть они или нет как это изменит каплинг?

Приветствую :) Подскажите плиз по SSO, правильно ли я понимаю.
Есть Центр Аутентифкации(ЦА) и 2 Сервиса (С1,С2), которые нужно "защитить".
Фронт проходит аутентификацию в ЦА, получает JWT, Потом с этим JWT ходит в С1 и С2.
Вопрос: С1 и С2 должны перед каждым запросом ходить в ЦА для проверки JWT  или же иметь свою систему проверки JWT (выходит что она копипастная + должны быть единые ключи, но зато без лишнего запроса)? Или и то, и то имеет право на жизнь, но зависит от проекта, тогда на что смотреть при выборе?

так вроде как раз смысл jwt в том, что не надо ходить никуда. Не очень понял про копипасту - ЦА подписывает jwt, а сервисы только проверяют подпись и время, до которого jwt валиден

там ключ не симметричный используется

Ну чтобы разкодировать JWT нужны ключи, разве нет?

нет, он же не закодирован, только подписан

Ок, подпись проверить ключи нужны

Или я неверно понимаю для чего ключи?

нужен открытый ключ для проверки

А ЦА подписывает закрытым

Значит он должен быть на всех сервисах.

да, всё так