Все же добавлю пару замечаний по решению:
-
операции над монетами могут показаться чересчур неэффективными по производительности - я над этим вообще не заморачивался, хотел больше модельной выразительности.
-
из задания не совсем понятно, что происходит с монетами, которые покупатель кидает в автомат - лежат ли они в отдельном приемнике и не отображаются в итоговой сумме или нет. Что будет, если в какой-то момент после покупки у нас получается ситуация, когда мы не можем выдать сдачу (из имеющихся монет нельзя сложить нужную сумму)? Я эту проблему решил так : покупка считается недопустимой, если мы после нее не можем вернуть сдачу.
-
операции внутри автомата реализованы атомарно, однако по-хорошему и операции вида "пользователь сделал, автомат сделал" тоже должны быть таковыми. Я не стал над этим заморачиваться умышленно.
-
исключения довольно формально реализованы - просто сообщения об ошибкам на доменном языке. И скорее всего не везде, где нужно, есть явная валидация
-
persistence layer заменен внедренной зависимостью на шарящиеся экземпляры юзера и кофеавтомата для простоты. Мне показалось, что так можно и легко протестировать функциональность и вроде как без особых заморочек с необходимостью где-то держать состояние.
-
юнит тесты здесь скорее формальность - времени не было покрыть по-нормальному. Поэтому они большие и нехорошие, т.к. тестируется сразу несколько функциональностей - это по сути была моя проверка, что код хотя бы примерно работает.