Здравствуйте, Pauel, Вы писали:

S>>>Если мы уже дошли до вызова ф-ии из BL, значит с авторизацией вопрос решили, соотв. идемпотентность -- это требование к BL, отсюда явное присутствие этого параметра на этом уровне.
F>>Не вижу логики, что это обязательно именно требование к BL.

P>Очень просто — средства на оплату конкретного заказа должны быть списаны ровно один раз вне зависимости от того, сколько попыток было оплатить.
P>Это БЛ. Все остальное есть просто реализация вот такого требования.

Это бизнес-требование, которое может быть реализовано как идемпотентной операцией, так и без всякой идемпотентности (например так, что первое обращение списывает деньги и меняет состояние заказа и возвращает чек, второе дает ошибку, меняет внутренний счетчик попыток оплаты, отсылает СМС, и возвращает ошибку — совсем неидемпотентная операция, которая, однако, закроет вот этот требование единичной оплаты).

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