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

J>>просто добавляешь дополнительные проверки внутри can_increase_amount.

M>Добавь, пожалуйста. Я же не просто так прошу привести пример законченного решения

bool can_increase_amount(Order o)
{
if (
если заказ помечен как кредит
если заказ помечен как удаленный
если заказ помечен как пассивный
если заказ помечен как замороженный
если заказ помечен как предоплата
если заказ помечен как оплаченный по предоплате
если в заказе нет товаров, которые можно вернуть

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

если сумма увеличивается, а заказ проведен через новую систему
если мы возвращаем деньги клиенту, заказ находится в одном из трех статусов, не является кредитом, и возвращаемая сумма меньше, чем максимальная разрешенная к возврату сумма
)
  return true;
else
  return false;
}

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

Естественно, это не убережет нас от ошибок в реализации can_increase_amount (и далее от этих слов читай в исходной статье http://rsdn.ru/forum/philosophy/5949645.1

Автор: jazzer
Дата: 10.02.15

)

соответственно, придется писать тесты на правильность реализации can_increase_amount, но не придется дополнительно проверять, что мы не вызываем финальную increase_amount не в том месте.

Как видишь, все есть в статье, если ее прочитать до конца.

You will always get what you always got
  If you always do  what you always did