DDD: Как предотвратить сохранение покупки без соответствующего отзыва

Предположим, что Сотрудник может приобретать продукты, используя своего рода «социальные кредиты», предоставляемые его Работодателем.

У меня есть сущность CreditsAccount, которая содержит сумму кредитов и ссылку на сотрудника, и я хочу смоделировать Purchase как сущность, которая содержит ссылку на CreditsAccount и продукт, который покупается.

Если у меня есть метод PurchaseRepository.save(), как я могу предотвратить сохранение Purchase без вывода из CreditsAccount?

Решение 1

Покупка является субъектом совокупного CreditsAccount, у меня нет PurchaseRepository, но вместо этого есть метод в учетной записи, такой как CreditsAccount.AddPurchase(purchase), который выполняет внутреннее снятие средств. Когда я сохраняю CreditsAccount с CreditsAccountRepository.save(account), я также сохраняю покупку в соответствующей таблице.

Но это означает, что каждый раз, когда я загружаю CreditsAccount для совершения новой покупки, я также должен загружать список покупок в этой учетной записи, верно?

Решение 2

Я создаю новую сущность PurchaseTransaction, которая содержит ссылку на CreditsAccount и Продукт, и предлагаю такой метод, как PurchaseTransaction.commit(). При фиксации он фактически производит снятие средств со связанной учетной записи, основываясь на цене Продукта, и его внутреннее состояние переключается с uncommitted на committed. Затем у меня есть PurchaseTransactionRepo.save (PurchaseTransaction), который:

• Если транзакция не зафиксирована, ничего не делать или вызывать ошибку
• Если транзакция зафиксирована, сохраните CreditsAccount с новой суммой и создайте Purchase в соответствующей таблице.

В этом случае PurchaseTransactionRepo предлагает только метод записи в базу данных, поскольку на самом деле PurchaseTransaction действительно не принадлежит какой-либо таблице, в то время как PurchaseRepository доступен только для чтения и предлагает только методы для получения «совершенных» покупок.

Что мне не нравится в этом решении, так это наличие репо, которое на самом деле создает своего рода логику проверки состояния PurchaseTransaction (зафиксировано или нет), а также вводит в заблуждение то, что Uncommitted PurchaseTransaction на самом деле не сохраняется.

Можете ли вы предложить мне другие решения, соответствующие концепции DDD?

Некоторый контекст: не настоящее приложение, а упражнение по ката, в котором мне нужно провести рефакторинг с анемичной области на более богатую. В анемичном есть сервис, выводящий счет и сохраняющий покупку за одну транзакцию. Затем я могу получить список покупок с помощью вызова API. Я хочу смоделировать его с помощью богатых сущностей и «принудительно» сделать недопустимые состояния «непостоянными».