Type RoleRepository interface { CreateRole(ctx, role) (role,

error)
UpdateRole(ctx, role) (role, error)
DeleteRole(ctx, id) error

AddPermission(ctx, roleId, permission) (permission, error)
}


Вот например, на AddPermission я сталкиваюсь с тем, что нужно указание roleID, хотя Permissions самостоятельны и существуют без roleID (для гибкости)

👉🏻 значит ли это, что permission - самостоятельная сущность? возможно

- значит ли это, что роли могут существовать без permissions? значит

Короче говоря, у меня отношение многие ко многим, поэтому объекты умеют существовать самостоятельно. Но тем не менее, логически в рамках системы они связаны

Я считаю, что должен быть RoleRepository и PemissionRepository

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

А зачем тут вообще общий? Пермишены отдельно могут существовать. Роли - тоже. И пермишен может добавляться в роль. Добавление пермишена в роль - это метод внутри репозитория ролей

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

Если тебе надо обыграть транзакции внутри репозитория, то тебе придётся сделать общий репозиторий, в котором будет некий метод, в котором будет в транзакции делаться запись во все 3 таблицы сразу. Если тебе хочется иметь 3 разных репозитория, то, очевидно, тебе транзакцию придётся выносить выше - т.е. в слой бизнес-логики. И для вот этого случая я тебе выше скинул фрагмент кода, который я использую именно для такой цели. Это два разных подхода. Кто-то предпочитает первый, а кто-то второй. И у каждого своё видение на плюсы и минусы

Да, в теории всё понятно, но на практике возникают вопросы, на которые без опыта сложно ответить Буду рад, если кто-нибудь подтвердит или опровергнет выдвинутые мной тезисы

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

Возможно. Но в финтехе такое сплошь и рядом

"Потому как репозитории оперируют агрегатами" - нигде в определении паттерна репозиторий не видел подобного утверждения

Поищите в первоисточнике в книге DDD.

In spite of all the machinery behind the scenes, Repository presents a simple interface. To code that uses a Repository, it appears as a simple in-memory collection of domain objects. fowler

A REPOSITORY represents all objects of a certain type as a conceptual set (usually simulated). It acts like a collection, except with more elaborate querying capability. Objects of the appropriate type are added and removed, and the machinery behind the REPOSITORY inserts them or deletes them from the database. Evans

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

Тем что протекает абстракция. КОд вне репозитория знает о том, что у тебя там sql.Tx, а не должен

machinery BEHIND. вынос транзакции выносит деталь имплементации хранения(собственно транзакции) из слоя репозитория в слой БЛ

Ну у меня ж транзакция не явным образом используется, а через транзакционный менеджер. Ничего не мешает подсунуть БЛ его другую имплементацию

Не знает. Потому что он дёргает транзакционный менеджер, не зная, как он внутри реализован

ему уже призходится знать, что нужна транзакция:)

Транзакции в БЛ вполне обычное явление. Само понятие транзакции не привязано к SQL непосредственно. Атомарность действий может быть реализована и иначе

Именно так и высвечивается проблема неправильного анализа предметной области. Об этом кстати тоже в DDD написано.

Не соглашусь. Для меня DDD не является библией)

А при чем тут библия? Вы просто подменяете понятия. Вы конечно можете черное называть белым. Но смотреть на это будут странно.

Никто и нигде не будет смотреть странно. В куче финтех-галер так сделано (ещё до меня причём) - и никто не считает это кривой реализацией.

Точно внутри репозитория ролей? По-моему, репозиторий ролей должен агрегировать ролями У меня, репозитории, по сути - это отражение таблиц бд, принимающие и отдающие бизнес-сущности Очень хочется сделать отдельный репозиторий для таблицы соотношений.. (но возможно, что это протечка деталей хранения)

Просто перестань называть это Repository, чтобы у адептов DDD все встало на свои места 😄

Нет. Я только сегодня создал с десяток файлов, назвав их BlablaRepository.go, и останавливаться не намерен!