клюс сессии достаточно сильно на практике отличается от того же самого jwt, содержащего все нужные для ответа данные.
В случае с jwt мы можем где-то на api gateway, policy descision point, самом сервисе обработки запроса, да даже на клиенте, замаппить /me/ в /users/1 вообще без обращения к каким-либо ресурсам, что сильно упрощает инфраструктуру и логику приложения. При этом /users/1 может шардироваться между инстансами и роутится по логике mod(userId,10), кэшироваться, кэшироваться в самом браузере на основе etag и вообще подвергаться всяческим оптимизациям просто потому, что оптимизируют как правило правильные решения, а не костыльные поделки. И информации по работе с правильными решениями значительно больше
Это элементарное транзакционные изменение свойств пачки объектов, ничего интересного — один из сервисов управления сотрудниками, и пачка событий в бухгалтерский сервис, сервис отчетов, офисный сервис, персонально вмем учатникам процесса, чтобы сохранить прозрачность изменений…
Это уже метод не объекта, но сервиса. Объекты не нетвечают друг за друга, а только используют. Если человеку дать корм и кормушку — он положит корм в кормушку. Если дать корм и кошку — то корм будет положен в кошку. Если дать кормушку и кошку… ну вы поняли.
Чтобы проконтролировать, что все прошло по замыслу всевышнего имеет смысл создавать более общие методы, которые проверят все предусловия и проконтролируют результата — сервисы, команды, контроллеры, стратегии, саги и прочие поведесчкие шаблоны.
В них мы можем реализовывать уже более сложные стратегии — начиная от генерации ошибки, если кормушка не пустая перед началом следующего кормления и заканчивая измерением глюкозы в крови кошки в процессе питания и привязкой человека к кошке, пока эта глюкоза не окажется в заданных пределах.
Тут должна для полноценного моделирования быть протечка абстракции, как и описано — корм положен в кормушку, кошка позвана, не хватает только таймер следующего кормления перевести на четыре часа вперед. То что кошка не поела — сугубо кошкины проблемы.
С чего вы взяли что детальная декомпозиция это плохо? Зачастую это совсем не так. И лучше, если там будет тысячи тасков, если это на самом деле позволит оптимизировать процесс.
От излишней декомпозиции можно защититься измеряя количество более верхнеуровеных тасков.
А что делать если модуль обслуживает потребности нескольких акторов? Копировать его рядышком?
А если этот модуль используется несколькими другими модулями?
Нормальные микросервисы — это когда не 5, не 10 сервисов, а 1000-5000 на тот же размер кода. И все это независимо мастштабируется в контейнерах для полноценной утилизации ресурсов. На такую крайность мало кто идет.
В случае с jwt мы можем где-то на api gateway, policy descision point, самом сервисе обработки запроса, да даже на клиенте, замаппить /me/ в /users/1 вообще без обращения к каким-либо ресурсам, что сильно упрощает инфраструктуру и логику приложения. При этом /users/1 может шардироваться между инстансами и роутится по логике mod(userId,10), кэшироваться, кэшироваться в самом браузере на основе etag и вообще подвергаться всяческим оптимизациям просто потому, что оптимизируют как правило правильные решения, а не костыльные поделки. И информации по работе с правильными решениями значительно больше
А в офисе они обучались или приходили-уходили и делали вид что работали?
Чтобы проконтролировать, что все прошло по замыслу всевышнего имеет смысл создавать более общие методы, которые проверят все предусловия и проконтролируют результата — сервисы, команды, контроллеры, стратегии, саги и прочие поведесчкие шаблоны.
В них мы можем реализовывать уже более сложные стратегии — начиная от генерации ошибки, если кормушка не пустая перед началом следующего кормления и заканчивая измерением глюкозы в крови кошки в процессе питания и привязкой человека к кошке, пока эта глюкоза не окажется в заданных пределах.
От излишней декомпозиции можно защититься измеряя количество более верхнеуровеных тасков.
www.youtube.com/watch?v=sVHU9z6M_XE
А если этот модуль используется несколькими другими модулями?
Нормальные микросервисы — это когда не 5, не 10 сервисов, а 1000-5000 на тот же размер кода. И все это независимо мастштабируется в контейнерах для полноценной утилизации ресурсов. На такую крайность мало кто идет.
Интересно, я это пропустил, когда выбирал диски себе или же этой информации не было? Вангую что второе…