Decorator это когда ты пишешь много декораторов которые добавляют другому обьекту какую-то функциональность. Обьект можно пропустить через несколько декораторов и у него добавится что-то от них. А тут больше на Proxy похоже.

Давайте внесу некоторые пояснения, чтобы картина была полной. Тестировали 1.5 года назад(возможно сейчас все гораздо лучше). На сервис брокере был поднят сервис API gateway service и отдельно две ноды воркера которые отдавали json на 2к строк. Стратегия балансировки раунд-робин.  Предположили, что такая конфигурация в состоянии держать 50к, на 20к пошли потери и к 30-40к оно просто умерло. Без всяких предупреждений и попыток восстановиться.
Перед тем как использовать технологию, первый вопрос, который я задаю себе  - “Какой профит я получу (какие проблемы решит эта технология).”  Предполагается, что микросервисный фреймворк, в первую очередь решит проблемы с межсервисной балансировкой, и добавит стандартный шаблон сервиса, в котором уже все разнесено по слоям, что в дальнейшем должно упростить расширяемость и поддержку проекта.  
Если мне нужно масштабировать сервис брокера с API gateway , то наверно, что-то пошло не так и я уже делаю балансировку над балансировщиком. Напрашивается вопрос зачем мне это ? Ведь эти вопросы должен решать фреймворк. Если я уже балансирую нагрузку между сервис брокерами с API gateway, то мне совершенно не сложно балансировать и между сервисами, и фреймворк для этого мне не нужен. Все что нужно толковый шаблон сервиса с нормально нарезанными слоями.  Еще смущает использование в molecular socket.io, express, это явно не добавит rps, хотя возможно это добавлено по “просьбам страждущих”. Было бы справедливым признать, что свой шаблон мы писали опираясь на подход molecular, в этом он мне импонирует. Т.е. если вы никогда не имели дела с микросервисной архитектурой, то molecular неплохой старт, для того чтобы собрать свою пачку граблей.

Это вы еще не видели как я маме рассказывала про code style на примере борща! Говорю вот все варят но каждая по своему. Так и у программистов. Все пишут код но каждый по своему 😂😂 мама уже шарит

Это вы еще не видели как я маме рассказывала про code style на примере борща! Говорю вот все варят но каждая по своему. Так и у программистов. Все пишут код но каждый по своему 😂😂 мама уже шарит

интересно, кто где описывает документацию к проектам если вы работаете в команде?

Прямо в репозитории проекта в маркдаун файлах? Или заведена отдельная вики? Или notion io, или еще чего?

Под документацией подразумевается описание API, описание концептов, просто словесное описание нюансов проекта, документирование принципа математических расчетов и других бизнес процессов.

Комментировать все прямо в коде получится вообще беспросветная лапша.
Интересно у кого какой опыт.

Очень интересно перенять опыт

У нас было в гите. Потом перенесли в Confluence. Но сейчас видно что лучше в Гите, рядом с кодом. Иначе код меняют а доки забывают

интересно, кто где описывает документацию к проектам если вы работаете в команде?

Прямо в репозитории проекта в маркдаун файлах? Или заведена отдельная вики? Или notion io, или еще чего?

Под документацией подразумевается описание API, описание концептов, просто словесное описание нюансов проекта, документирование принципа математических расчетов и других бизнес процессов.

Комментировать все прямо в коде получится вообще беспросветная лапша.
Интересно у кого какой опыт.

Очень интересно перенять опыт

На практике часто получается, что это очень трудозатратно. Особенно поддерживать документацию в актуальном стостоянии.