Господа, есть вопрос Вот есть условный доменный пакет в рамках DDD

и гексагона

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

Но при этом работать с ней как-то нужно. Я пришел к тому, что создавать транзакцию непосредтсвенно в хендлере, передавать в домен как параметр (DI интерфейс), а потом при ошибке в конце делать роллбек, иначе делать коммит.

Но при этом получается, что нужно протаскивать этот параметр DI интерфейса БД через все методы домена, что мне кажется очень некрасивым.

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

Что думаете? Нормально ли таскать транзакцию через все методы, либо лучше положить ее в контекст (он и так везде передается), либо создавать доменный объект вокруг транзакции?

Паттерн Unit of work, клади в контекст флаг о том, что оно должно быть внутри транзакции.

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

Что-то вопрос не могу уловить, домен не должен знать о транзакции но управлять ей должен уметь?) Не выходит тут противоречия?

Домен не должен знать ничего про базу данных. А если использовать sql транзакции, то ты прям в коде домена будешь писать sql.Begin, sql.Commit и т.п.

Тоесть про транзакцию он ничего не знает, а про Save (aka Commit) может знать? Это не тоже самое другими словами?

Это не sql.Tx, это условный BusinessTx. То есть домен знает, что вот этот набор действий применяется одновременно. Но что там под капотом - домен не знает.

Транзакция концептуально есть, но она не инфраструктурная, а бизнесовая. В итоге ты можешь заменить базу на файлики, или postgres на redis, а домен останется неизменен, к примеру.

Попробую этот подход в одном из сервисов

Я видимо на хабр статью про это напишу :D Давно хочу, на самом деле. "Как работать с бд в го", что-то такое. А то нездоровая популярность gorm меня пугает.

Лучше на медиум. Нечего «этих» баловать.

Дай знать, почитаю 🙂

Это каких?

Которые меня забанили

Тогда уж лучше на dev.to На медиум невозможно технические статьи писать без боли

Этот подход, кстати, хорошо зайдет как быстрое решение при постепенном рефакторинге кода Можно на стороне БД написать обертку с транзакциями, на стороне хендлеров - добавлять юнит в контекст, а все, что между - не трогать

Ага.