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

Подсказал ей Волшебный шорткат Ctrl z

Вот бы ей туда autosave по onchange. Была бы вдвойне рада :)

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

и мб даже учесть, что да, человек может нигде не нажать сохранить, но данные нужны

в целом могу себе такую ситуацию представить.

ну автосейв не блочит undo

а вот если бы закрыла случайно. Было бы хуже

независимо от того, есть ли автосейв или нет

Всем привет!

Потребовалось решить в проекте две задачи:
1. Генерация счетов по услугам
2. Приём платежей.

Как мне лучше это организовать из нескольких сервисов: Invoice и Payment или же объединить их в какой-то общий: Finance, Money, Pay? Я склоняюсь к объединению. Что думаете вы? И как его назвать? Так же в будущем будет подписка и автоплатежи.

Сервис будет независимый. То есть у него будут свои Customers, Recipients, Services. И он никак не будет связан с другими сервисами. Разве что по ID. Здесь тоже вопрос есть. Как связывать квитанции с какой-то услугой извне этого сервиса? Использую UUID.

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

Помогите советом, пожалуйста) Пока в процессе построения диаграммы.

смотри на данные и как они используются. В частности все кейсы где нужна работа с актуальными данными (мол на основе них логика какая). Пользователю например задержка в 100-200 милисекунд по данным погоды никакой не делает (наши мозги и так с экрана это с задержкой восринимают)

Пеймент - больше про интеграцию с PSP (бридж-сервис), а инвойс (я его называю сейлз или OMS - там ведь могут быть рефанды) содержит больше бизнес-логики. Я бы разделил, чтоб, логику можно было использовать с бриджем другого PSP

Я у нас, кстати, проектировал обе эти части)
Причем пеймент-бридж проектировался для переиспользования с другими проектами (типа СааС)

Задержка, конечно, не особо сейчас важна. Тут у меня больше архитектурный вопрос))

Фактически да) я думал над разделением, но не думал почему лучше отделить) Наверное, вы правы. Стоит отделить оплату от счетов и уже интегрироваться по событиям через шину.

архитектурные вопросы должны приследовать практические цели. Иначе это просто игра в мамкиного архитектора. Все эти загоны по данным приследуют определенные цели.

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

У вас тут в чате бот кривой. Зашли одновременно 2 человека, обоим кнопку показало, но каждому чужую. В итоге обоих бот отправил курить ещё сутки. Вроде бы не критично, но осадочек остался.

Да-да, с Алексеем так было. Я свою нажал - меня пустило. А он или мою нажал или свою - его выпнуло.

Почему по вебсокетам не сделать?