Пытаюсь запилить модель покупки билета. Покупка билета осуществляется он-лайн через платёжный

шлюз.
Флоу, вот такой будет, думаю:
1. User заполняет форму, отправляет запрос на бэк с ид Tariff-а и Promocode-а(если есть)
2. На бэке достаётся из БД Tariff и Promocode
3. Дальше необходимо создать Invoice.
Но тут проблема:
- Если создавать Invoice со ссылками на Tariff, Promocode, User-а - тогда при изменении значений свойств любого из этих объектов, поменяются и свойства Invoice. А мне такого (изменения суммы оплаты между выставлением и оплатой Invoice-а и проч.) не надо.
Тогда можно:
- Создавать объекты с информацией для Invoice-а отдельно (создавая их из текущих Tariff-a, Promocode-a, User-a).
Но тут возникает другие проблемы:
- При пересчёте суммы Invoice-а (пользователь решил покупать по другому Tariff-у или у него Promocode появился) необходимо будет поведение Tariff-a и Promocode-а внутри Invoice-а.
Тогда можно:
- Добавить эту логику в 2 места - и в объекты внутри Invoice-а и отдельно в Tariff с Promocode, но это явно (ха-ха) одно и то же.
- Сделать расчёт через multiple dispatch передавая в метод Tariff, User, Promocode.
К тому же всё это не решает следующую проблему:
- Если воспринимать Invoice как часть write-model, которая пересчитывает сумму - тогда существует проблема невалидности Invoice-а после создания. Ведь нужно будет сначала создать Invoice без суммы, а потом вызвать метод расчёта суммы.
В попытках решить эти проблемы родились 2 идеи:
а. Invoice не должен содержать поведения по пересчёту суммы к оплате. Сумма должна передаваться в конструктор Invoice-a.
В конце концов, если User захочет другой тариф - будет создан новый инвойс, а старый просто будет не оплачен. И вообще - Invoice как отображение заказа не должен, наверное, содержать логики по пересчёту суммы оплаты для write-model, т.к. он относится к read-model.
б. Считать сумму Invoice-а в каком-то domain service-e (Payment?). (как решение последствий идеи а. - ведь кто-то должен взять на себя ответственность за пересчёт суммы к оплате)
4. Вычисляется итоговая сумма Invoice-a
5. Создаётся и сохраняется Invoice (с копиями данных Tariff, User, Promocode)
6. User-y отображается форма оплаты картой по созданному Invoice-у
7. User вводит данные карты и отправляет на бэк
8. Начинается оплата Invoice-а через платёжный шлюз.
Собственно вопрос - что думаете по поводу идей а. и б. ?
Вроде логично получается, но хз - может говна не почуял и проблемы через жопу решаю. Или проблемы вообще в другом месте (в голове, да :D)

а теперь попробуй убрать из своего описания процесса все технические нюансы

Если меняется сумма, то тебе нужно инвалидировать старый инвойс и создавать новый. Иначе никак. Если только условия, то so so, но лучше тоже пересоздать.