Здравствуйте, Pauel, Вы писали:
P>Очень просто — средства на оплату конкретного заказа должны быть списаны ровно один раз вне зависимости от того, сколько попыток было оплатить.
P>Это БЛ. Все остальное есть просто реализация вот такого требования.
Позволю себе не согласиться. Бизнес-аналитики вообще не должны мыслить вот этими категориями технических подробностей.
Есть бизнес-сценарий. Например — заказ такси.
Бизнес аналитик в первую голову анализирует функциональные потребности. Ну там — будем ли мы в рамках одного заказа давать ехать через N точек, или это строго A->Б?
Можно ли разделить оплату на нескольких пассажиров, или мы требуем строго 1 поездка = 1 плательшик?
А одному плательщику можно оплатить заказ частично картой, частично кэшем? А двумя картами?
Можно ли отменить заказ? А если водитель уже приехал? А если начал выполнение заказа?
Что делать, если клиент не выходит, но заказ не отменяет?
В какой момент списывать деньги — в начале поездки? В конце? Что, если поездка прервана посередине?

В первую голову, естественно, идут т.н. "позитивные" сценарии.
Потом начинаем критически смотреть на это — нет ли в нашей бизнес-логике дырок. Типа: таксист никуда не поехал, а тупо нажал "я прибыл", дождался "невыхода" клиента, получил компенсацию от сервиса, и побежал "брать" другой заказ. Или, например, наоборот — клиент вызывает такси, и за 30 секунд до прибытия машины отменяет заказ, и так 100 раз.
Или мы списали с клиента 100р за первый сегмент, начинаем списывать 500 за второй — а у нас отказ банка.

Изо всего этого строится большое-большое дерево решений; на их основе формируется набор требований.
Вот эти все подробности "ой, а что делать, если во время поездки рубануло питание датацентра?" — это вообще не вопрос бизнес-логики. Бизнес-аналитик (по крайней мере, в нормальной компании) не должен объяснять solution architect вещи типа "ребяты, надо все изменения держать в персистентной СУБД, и вся интеграция с внешними сервисами должна уметь восстанавливаться после сбоя".
И точно так же вопросы идемпотентности конкретных методов находятся в ведении архитекторов.
Это то же самое, как если бы аналитик должен был в каждом use-case добавлять строчку "а ещё программа должна работать корректно".
Или, к примеру, диктовал, какой протокол выбирать.
Если бы BA проектировал сервис типа DNS, то он бы наверняка большое внимание уделил таким вещам, как семейства записей и топология доменных зон.
Вещи типа TTL уже обсуждались между BA и архитекторами, которые бы объясняли, что для обеспечения нужного уровня надёжности база должна быть распределена, поэтому прямое управление кэшированием лучше игры в угадайку.
В процессе обсуждения в бизнес-логику проникли бы концепции вроде авторитативных и не-авторитативных ответов.
А вот вещи типа выбора UDP вместо TCP в качестве протокола, а также детали того, как клиент понимает, какой из пакетов ответа относится к какому запросу, вообще бы целиком решались на уровне архитекторов.
Это нифига не часть "бизнес-логики". Бизнес-логика там ровно та же, что и в HTTP — есть запрос, есть ответ. А вот какие конкретно будут методы в HTTP, или коды ошибок, или структура и нумерация UDP-пакетов — это слишком низкий для BL уровень.