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

Нет, нет. Удалять ничего без ведома пользователя - не будем.
Когда в коризне есть товары невалидные, то корзину делаем невалидной и показываем пользователю, что есть товар1 - который удален, товар2 - которого нет на складке. Либо удалите их, чтобы создать заказ, либо ждите, пока корзина снова станет валидной.
У меня пока такое в голове. Да я и смотрю доклад и больше склоняюсь к тому, что это не инвариант, а просто "другое состояние"

ну вроде тогда все ок) Удачи в реализации))

Только не удалите, а «давайте подберём замену» xD

Это уже реализовано 😅. Я зашел спросить правильно ли все делаю и думаю

Спасибо всем за ответы, практически разобрался с вопросом, надо дописать тестов к этому

вроде правильно)

Есть спецы по акторам? Начал раскуривать...возник вопрос: есть персистентные акторы, например для саг. Нода упала. Ее перезапустили, каким макаром нужно поднять персистентные акторы? Те самый простой вариант я храню где-то persistence id действуюих саг и при старте создаю акторы по id. Может есть какое решение из коробки? Например при старте попросить все id которые хранятся а сторадже или ещё как?

что ты имеешь ввиду под persistent актор?

Забыл указать что akka раскуриваю

Akka Persistence enables stateful actors to persist their state so that it can be recovered when an actor is either restarted, such as after a JVM crash, by a supervisor or a manual stop-start, or migrated within a cluster. The key concept behind Akka Persistence is that only the events that are persisted by the actor are stored, not the actual state of the actor (though actor state snapshot support is also available). The events are persisted by appending to storage (nothing is ever mutated) which allows for very high transaction rates and efficient replication. A stateful actor is recovered by replaying the stored events to the actor, allowing it to rebuild its state. This can be either the full history of changes or starting from a checkpoint in a snapshot which can dramatically reduce recovery times.

Ну написано, что энжин переигрывает все сторед ивенты чтобы рантайм состояние восстановить до момента когда оно упало.

Считай у тебя есть белый лист бумаги и последовательность указаний, как его согнуть и порезать, чтобы получилась снежинка

И эти ивенты событий и есть указания

Там все данные рантайм вообще, и сторейдж того чем оперирует вся система только рантайм, ивенты есть последовательные изменения рантайм состояния

Это да, + есть даже снепшоты, тут вопросов нет. Вопрос: было 100 акторов, нода упала, поднялась, нужно поднять 100 акторов которые были на момент падения. Не понимаю из доки кто за это отвечает

А хз

Добрый день. Немного начал разбираться с DDD, необходимо любое мнение по задаче, пока сам думаю.

Есть меню в ресторане: состоит из блюд и дополнений к нему. (например, блюдо - бургер, дополнения: лук, помидор и так далее). Дополнения могут быть обязательными (для суши обязательное дополнение - палочки) и необязательными (пример с бургером). Они могут быть вместе (например, 2 обязательных и 3 необязательных, но для блюда всего доступно на выбор 5 дополнений. У суши дополнения: палочки, сыр, огурец. Обязательные только палочки).

Правило: пользователь хочет добавить суши без палочек в корзину. Я должен дать ему ошибку, что отсутствует обязательное дополнение "палочки".

Что у меня сейчас получается:
У меня есть сущность Product и сущность Addition.
Сущность Product имеет несколько доступных ему Addition'ов. Они могут быть обязательными и необязательными.
Для корзины соответственно сущность Cart, CartProduct и CartAddition.
При добавлении блюда в корзину у меня получается тоже самое, только CartProduct с несколькими CartAddition'ами.

Проблема:
Я не могу положить блюдо в корзину без обязательных дополнений. Если сначала создать блюдо, а только потом добавить туда дополнения - будет момент, когда блюдо невалидно. Условно говоря в конструкторе CartProduct'а должны быть аргументы (Product и array<Addition>).
Но и в таком случае может быть ситуация, что обязательных дополнений 2, а мы добавили из них только одно. Снова инвариант.

Валидировать в конструкторе я не хочу, валидировать в другом объекте создателе CartProductBuilder'е выглядит небезопасно.

Где собственно эту ситуацию можно валидировать? Что можете посоветовать?

А Additional может заказываться отдельно от Product? Если нет, может не стоит их по отдельности добавлять в корзину, а создать промежуточный Order к примеру, где и будет валидироваться заказ по бизнес рулам определенным.

Нет, не может, только вместе. Т.е. корзина сама должна уметь валидировать входящие в нее Product'ы?