весь гос сектор это работа с хрустальным шаром

но даже там можно угадывать и работать, если есть опыт и понимание ожиданий

А потом удивляются, почему в госухе сплошной п.ц.

потому что там хотят порой модно, а порой чтобы знакомый делал

один раз обставили ребята, которые предложли серверлес для легаси системы, все расчеты которой укладывались в простой домен, а разрабов там было 3 чела. Срок был в 4 месяца.

Ну, у нас тоже бывают заказы от госа, но там знают, что мы в предметке и просто указывают доптребования к стандарту. И сбор требований до тендера проходит всё-таки.

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

не, тут о другом, что есть проблема хайпа, и люди не думают, а следуют "трендам"

иногда в формальном письме не получается донести, что хайп не сработает и надо идти проверенными простыми решениями, пока ваш кейс не доказан

Ну, тогда это уже не про предмет конкурса на арх.решение.

ок, Фил, есть конкретные предложения что можно улучшить и почему?

я хочу научиться, мне нужна обратная связь. Но конкретная

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

Да, есть какие-то "classical pairings", но их мало и они тоже все требуют пересмотра в зависимости от НФТ.

Я вот читаю гугловую постановку - и за каждой строчкой вижу бездну )

Например, одно из решений - взять готовый процессинг с мерчантовской кассой (OpenWay, ЦФТ или даже RBKMoney etc) и отконфигурировать.
Или купить решение в ДоДоПиццы и подкорректировать.
Тут можно в два месяца на все уложиться, например,  и будет, возможно, дешевле своей разработки.

Ну или систему для ресторанов (тут я  не компетентен, что там на рынке)

Конкретнее.
Вот https://github.com/ldynia/archcolider/blob/master/4.ADRs/007%20Event%20sourcing%20usage.md
Тут предлагается взять EventSourcing для, фактически, целей второй и третьей линии поддержки.
Но для этого уже есть система логгирования, которой полностью достаточно для этих целей для этого проекта.
В результате мне (как, например, принимающему архитектору) кажется, что ES добавлен ради моды, а не ради решения возникшей бизнес-задачи.
Более того, ES противоречит assimption, так как не является "major technologies available on the market"

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

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