Я пытаюсь не думать) собственно, это какая-то сущность, которая держит примерное состояние данных из внешней системы, умеющая и сама их запросить, если надо, и обновить, если снаружи апдейт прилетел, и кэшировать и при этом скрыть всю эту логику от других частей системы.

Пойду перечитывать Фаулера про gateway.

ну вот ответ на твой вопрос - "корректно ли бла бла " - размер "сущности" не влияет ни на что. влияет поведение и поток изменений. Разные системы - разные интеграции - разные штуки. Много маленьких штук лучше чем несколько больших

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

Принял. Спасибо.

У кого-нибудь есть готовая функция для приблизительного подсчета перцентилей на дата стримах?

Привет
Как хранить темплейты сообщений для ответа клиентам? (чат бот)

Есть json темплейты для сообщений, куда поставляется дата из сущностей или модели для чтения.

В базе? Const в коде?

как удобнее

Здравствуйте, вразумите пожалуйста по поводу того, как можно сделать правильную архитектуру на фронтенде.
С бэкендом ситуация потихоньку проясняется благодаря во многом этому каналу: делим все по вертикальным слоям/фичам, каждую фичу делим на горизонтальные слои (домен/приложение/инфраструктура). Граф зависимостей идет от инфраструктуры к домену, доменные объекты зависят только от контрактов/интерфейсов. Коммуникцаию между инфраструктурным слоем и прикладным реализуем через шину команд, активно используем DI контейнер и вот это вот все.

А как быть с фронтендом если у нас SPA и часть бизнес-логики должна крутиться на стороне клиента? Можно ли аналогичным образом подойти и здесь, поделив все на слои подобно бэкенду? По идее, сам UI это же инфраструктура? А если есть некоторые бизнес-требования относительно его поведения (что по идее относится к домену), как разнести это по слоям?

крутое видео для людей типа меня, кто не осилил Ларри Константина

не, UI это UI, у тебя есть инфраструктура которая собирает этот UI. И да, UI компоненты будут сильно привязаны к фреймворку (не выйдет реакт компоненты так вот вжух и теперь ангуляр и т.д.)

В целом все примерно так же как и на бэке, точно так же можно изолировать бизнес логику и обмазаться стэйт менеджментом сверху (всякие effectorjs, recoil, etc). Точно так же можно дробить по функционалу, и функционал по "слоям".

Более того - есть скажем микрофронтенды, composite UI, вот это все.

правила одни и те же по сути... идеи и принципы теже. Есть "нюансы" что в целом сложно изолировать инфраструктуру и в целом не оч понятно стоит ли загоняться (это и с бэком не сильно понятно).

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

@fes0r а почему ты , раз) не спишь в 1мск ? два) почему не хочешь кому-то делегировать изложить ответы вот эти, ты их уэе не раз высказывал?

1. потому что у меня режим дня такой
2. потому что все еще мне не нравится формулировка. Каждый раз повторяя мысль я ее пытаюсь сформулировать как-то по другому. Ну а если после этого еще и вопрос как-то по другому зададут или пример какой накинут - ух.

круто.

@fes0r а что смотришь на ютьюбе ?)

эт совсем оффтоп

ну да) прикольный оффтоп такой