Выходит достаточно иметь одну либу на всех сервисах (ЦА,С1,С2) и расшарить паблик кей (возможно программно, чтобы ЦА отдавал его).

Спасибо :)

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

Ну если допустим готовое решение по JWT без SSO, то просто установить его везде и расшарить паблик кей.

д

👍😂

Приветствую :) Разъясните плиз :) Пример из книжки (не DDD, об этом вопрос), поэтому мб будет кому то знакомым.
Есть компания (аксессоры - количество менеджеров, домен компании ),  
Есть юзер (аксессоры - емейл, тип пользователя)
экшен: смена емейла у пользователя. условия: если емейл подходит под корпоративный домен компании, то у польхователь становится менеджером (ну и наоборот), а у компании меняется количество менеджеров.  
Следуя принципу TellDontAsk, все действия инкапсулированы + для уменьшения сервисного слоя компания передается прямо в метод пользователя changeEmail. Код (C# вроде) https://pastebin.com/hWrLkRCq

Вопрос. По DDD есть такое что "Агрегаты общаются друг с другом только по ссылке" для уменьшения каплинга в системе. Тут, как я понимаю,  это два небольшие, но агрегата. Что тогда означает "только по ссылке", раз тут юзер знает о компании в своем методе? Как тогда должно быть?  Или "только по ссылке" относится для агрегатов в разных ограниченных контекстах, а в одном контексте агрегаты вполне могут знать друг о друге? Ну или я возможно не совсем понимаю значение "по ссылке", я это понимаю как один агрегат знает о другом только ID и больше никак с других агрегатом не связывается в своих методах .

Советовал бы вам отказатся от методов вида changeNumberOfEmployees(). У вас есть компания, которая не меняет число сотрудников, но может нанимать или увольнять сотрудников. Потому методы логичнее сделать в виде hireEmployee() и fireEmployee(). И то правило что вы озвучили - это правило найма и его логичнее отобразить в соответствующем методе. Иными словами, в том условном методе hireEmployee() будет происходить добавление сотрудника (оно же и фактически увеличивает их количество) и проходить проверка того будет ли он менеджером исходя из email-домена

Спасибо, тоже об этом думал, так как эти методы более понятно описывают бизнес действия.  Там правда не найм сотрудника, так как клиент вообще может не относиться к компании, и в холостую делать hire не совсем верно наверное будет.  
Но опять таки это скорее детали конкретной реализации и предметной области, и даже если мы поменяем по вашему предложению, на мой вопрос это никак не отвечает :(

Я просто не увидел у вас проблемы ни в чём другом кроме этого. У вас недостаточно предметной области что бы определять контексты, агрегаты и прочие вещи. Как следствие, не совсем понятно где там проблема взаимодействия контекстов

Два агрегата: Юзер, Компания. В прицнипе это просто пример, вопрос скорее теоретический. Могут ли по ДДД Агрегаты общаться друг с другом в своих методах? Ведь есть "агрегаты общаются друг с другом только по ссылке".

Просто два варианта:
1) Могут: уменьшается кодовая база сервисного слоя. Код ставновится более инкапсулированный.  Но тогда повышется каплинг между агрегатами. Не понятно тогда что значит из теории фраза "агрегаты ссылаются друг на друга по ссылкам".
2) Не могут: сервисный слой растет, инкапсуляция падает (это спорно, но больше к тому, что принятия решения выходит за рамки агргегатов, когда им требуются некие данные/результаты других агрегатов). Но снижается каплинг. Агрегаты знают друг о друге только ID

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

Отвечая более буквально - могут общаться, могут не общаться 🙂

Спасибо за развёрнутый ответ 👍

привет, ребята! а встречал ли кто-то адаптацию опентрейсинга для SPA?

для фронта в браузере?

https://docs.sentry.io/platforms/javascript/performance/ есть таке

Ну я больше с точки зрения теории... Опентрейсинг - больше идея чем реализация. Но там про RPC. А что делать с контекстами внутри приложения - непонятно.