Как в коде в стиле «clean architecture» использовать транзакции?

Question

[NubasLol]

Пример репозитория

https://github.com/bxcodec/go-clean-arch

Смотрел примеры, как выше, читал статьи но так для себя и не понял. Что делать с транзакицями. Ведь методы репозитория не принимают ничего кроме данных. По итогу решительно не ясно.

Например у меня есть OrderUseCase {orderRepository, paymentRepository}

И метод newOrder()

Как правильно в нем написать, что бы создание заказа, и списание средств со счета пользователя было в транзакции. Или это все нужно пихать в 1 репозиторий, но потом будет дублирование кода ведь?

Comments

[raiboon]

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

[NubasLol]

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

Ну их ведь и без транзакций можно использовать, что бы сохранять сущность и ее зависимости. И извлекать.

Звучит интересно, но вот пугает, что придется создавать под каждый возможный вариант зависимостей свой агрегат, по хорошему

[dmitriy]

Order - агрегат с вложенными объектами, все операции транзакции внутри репозитория агрегата

проявиться так же много агрегатов и много дублирования.

приведите пример

[NubasLol]

dmitriy, пример у заказа может быть промокод, а может его не быть.

Это будет один агрегат?

[NubasLol]

Ну или ещё, у заказа есть товары, их нужно выводить в списке заказов, ещё товары есть в каталоге. А ещё товары есть в рекламных акциях.

Для каждого такого действия нужен свой агрегат и свой репозиторий?

[dmitriy]

может промокод существовать отдельно от заказа?, могут ли в заказе быть позиции заказа, могут позиции существовать отдельно от заказа наверно если не могут то 100% агрегат

товары - скорее всего товар может существовать отдельно от заказа, может ли товар быть без раздела наверно нет, может ли раздел бы без каталога, тоже наверно нет. эти вопросы нужно задавать при проектировании в первую очередь.

в приведенном примере можно выделить два контекста: Заказ и Каталог
в контексте заказа существует Агрегаты: Заказ, наверно могут быть также Покупатель, Доставка, Оплата как отдельные агрегаты так как доставка может быть без заказа
в агрегатах связи с другими агрегатами могут быть по uuid
например в заказе есть связь с покупателем order->shopperId = 1; а может быть объект order->shopper->getName()
у покупателя связь с заказами может быть Shopper->orders = [123,123]
позиция заказа может иметь связь с товаром OrderPosition->productId = 123;

все это больше перевес в DDDшную тему

Answer 1

[Roman K]

Нужно понимать, что orderRepository и paymentRepository — это абстракции, а фактически данные могут храниться как в одной базе, так и в совершенно разных. Например, orderRepository находится на сервере S1 в базе Redis, а paymentRepository — на серверах S2, S3, S4 в базе PostgreSQL. Поэтому, классические транзакции здесь неприменимы. Этим можно пренебречь в большинстве случаев и не переусложнять систему, а можно пойти "правильным" путём и использовать распределённые транзакции, например, саги https://microservices.io/patterns/data/saga.html

Comments

[NubasLol]

В моем случае все же данные хранятся в одной бд (postgres и будет что-то типо bolta или sqllite). По этому у меня главным образом вопрос был в том, что если у меня есть OrderRepository могу ли я в нем ходить в другие таблички. Ну даже если это будет дубль функционала из paymentRepository

За совет спасибо, буду изучать!

Answer 2

[Михаил]

Тут все довольно просто. У нас есть слой бизнес-логики, который имеет 3 интерфейса:
TransactionManager - собственно менеджер транзакций
OrderRepository - репозиторий заказов
PaymentRepository - репозиторий платежей

И, допустим, нам нужно транзакционно сделать следующий сценарий: "при получении платежа записать его в БД и изменить статус заказа на PAID" (пишу пример на Kotlin, надеюсь понятно)

transactionManager.inTransaction {
  order.status = PAID
  paymentRepository.save(payment)
  orderRepository.save(order)
}

Собственно дальше - это уже вопрос реализации TransactionManager. Если мы имеем дело с простым случаем, таким как хранение данных в SQL Database, то его реализация должна быть понятна. Если более сложный случай - то распределенные транзакции, либо пустая реализация (транзакционность не поддерживается). Разумеется, при инжекции зависимостей в модуль бизнес-логики реализация менеджера транзакций должна соответствовать реализации репозиториев (мало толку будет если менеджер транзакций реализует транзакционность в БД, а репозитории - хранение в файлах). Но это уже слегка другой разговор, тут на помощь приходят фабрики и подобные шаблоны.

Comments

[NubasLol]

Спасибо!

А если разделять по доменам, где бы вы положили этот transactionManager? Ну условно есть пакет orders и пакет payments сейча. Нужен какой-то третий пакет?

[dmitriy]

Тут все довольно просто. У нас есть слой бизнес-логики, который имеет 3 интерфейса:
TransactionManager - собственно менеджер транзакций

ну вы понимаете что в бизнес логике нет никаких транзакций?

[NubasLol]

dmitriy, Правильно будет создать агрегат а не транзакцию, а вот уже как он будет сохраняться отдавать на откуп репозиторию?

[Михаил]

dmitriy,

ну вы понимаете что в бизнес логике нет никаких транзакций?

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

[Михаил]

NubasLol,

А если разделять по доменам, где бы вы положили этот transactionManager? Ну условно есть пакет orders и пакет payments сейча. Нужен какой-то третий пакет?

Я бы разложил по пакетам так:
domain - слой бизнес-логики (внутри может быть разбил по пакетам в зависимости от объема оной бизнес-логики
domain.storage - интерфейсы к репозиториям, в том числе интерфейс TransactionManager (так как он напрямую относится к логике сохранения)
platform - платформенные реализации интерфейсов
platform.repositories - реализации репозиториев, включая TransactionManager.

platform (детали) зависит от domain (бизнес-логика) в полном соответствии с принципами clean architechture, но не наоборот.

[dmitriy]

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