ты про видеокарты что-ли?

Да

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

Там сам процесс чекаута проходил нормально, да

так у большинства "крупных" магазинов. Время от "хм... надо бы купить" до "списали и оформили заказ" нужно уменьшать до возможного минимума. Эталон - amazon one-click purchase. Кликнул и все. Оч хорошо работает с импульсивными покупками

Тогда как борешься против ботов? Грубо говоря

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

если ты первый раз покупаешь можно и подольше процесс, если ты постоянный покупатель то надо поощрять твою импульсивную манию покупать всякий булшит

Прекрасное: "...моделирование бизнес-структур, по сути, было убито родственной Agile дисциплиной: Domain Driven Design (DDD). Ограниченные контексты инкапсулируют (заметают под ковёр) сложность, чтобы энтерпрайз мог масштабироваться на «команды на две пиццы». "
https://habr.com/ru/company/vdsina/blog/561272/

Помянем

> Современная парадигма заключается в том, что нам всё равно не удастся понять задачу. Гуру цифровой трансформации говорят нам, что нужно разворачивать продукты в продакшен, чтобы пользователи сами говорили, в чём заключаются бизнес-требования, а не формулировать их самостоятельно априори. Благодаря этому мы можем сделать несколько попыток, чтобы реализовать всё правильно. Да, в этой парадигме нужно ошибаться быстро и часто.

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

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

Я понимаю что тебя тут возбудил именно наброс что "DDD в чем-то виноват". Хотя опять же, закон конвея никто не отменял, как и закон брукса.

p.s. важно понимать что далеко не всегда информации недостаточно что бы применять всякие 6 sigma и прочие более ватерфольные процессы. Более того - вот эти все "самоорганизующиеся команды с горизонтальными связями" - к этому как-то надо придти и большинство компаний на стадии когда "ой лучше нанять аналитика и ватерфол-лайк подходы". Особенно когда от идеи до продакшена измеряется не днями/неделями а месяцами

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

берешь big picture event storming модель

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

p.s. я лично UML юзаю, хоть и редко. Оч удобно отдельные процессы связанные с интеграциями описывать.

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

я никогда не забуду сторю

As investor
I want to Invest
to became an investor

К слову написанную "бизнес аналитиком"