СП
м... наверное даже домен знает, это ведь требование бизнеса
Size: a a a
2021 June 14
V
Я не про это, а про то, что некоторые записи не могут быть роллбэкнуты
SP
Условно у нас есть бизнес операция - юзкейс какой-то. Это у нас на уровне application. В рамках этой операции нам надо совершить две логические транзакции - каждая со своим агрегатом.
SP
Очень упрощённо - домен предоставляет маленькие логические транзакции из которых ты собираешь юзкейсы
СП
Да, всё так.
Для примера, система учета денег. Много счетов. Есть счета, которые заводятся для клиентов. При создании клиента должен создаться счет для него и привязаться к клиенту.
в рамках юзкейса:
- создать счет
- создать клиента
Эти две операции либо должны быть выполнены транзакционно
Для примера, система учета денег. Много счетов. Есть счета, которые заводятся для клиентов. При создании клиента должен создаться счет для него и привязаться к клиенту.
в рамках юзкейса:
- создать счет
- создать клиента
Эти две операции либо должны быть выполнены транзакционно
СП
Думаю еще как вариант вместо транзакций для application уровня сделать интерфейс с методом наподобие
saveNewClientWithAccount($client, $account)
saveNewClientWithAccount($client, $account)
SP
и что это тебе даст?
СП
инфраструктура будет однозначно знать что нужно сделать одновременно
SP
ну то есть такой вот unit of work для бедных?
СП
Вроде того выходит :)
СП
Хотя такое упрощение в конечном итоге может усложнит код...
SP
ну вот надо задаться вопросом какую цель ты приследуешь. Сразу оговорюсь что к DDD это все имеет не оч большое отношение - оно может помочь с моделированием и декомпозицией, дальше просто separation of concerns coupling/cohesion, information hiding все дело делает
SP
главное что бы было легко проследить как данные меняются, что бы предсказуемо
СП
Как ни крути всё равно приходится учитывать инфраструктуру при проектировании application-слоя. Если я знаю, что в рамках текущего контекста у меня всё в одной БД, то можно смело делать TransactionManagerInterface и его использовать - можно быть уверенным, что проблем не будет.
СП
Хотелось выработать какой-то универсальный подход.
DT
Сага же может быть границей транзакции
DT
Само название метода говорит что это 2 разные операции, которые могут быть запущенны по отдельности.
Если у тебя клиент не может существовать без счета в принципе (или наоброт), и тебе так важно это все засунуть в транзакцию, то Сделай это правилом а метод юзкейса назови addClient
Если у тебя клиент не может существовать без счета в принципе (или наоброт), и тебе так важно это все засунуть в транзакцию, то Сделай это правилом а метод юзкейса назови addClient
СП
да, но это сильно усложняет реализацию
СП
другой счет может быть без клиента создан, а вот клиент всегда со счетом должен создаваться.
В application слое это и называется createClient и в этом методе уже нужно транзакционно сделать и счет и клиента.
Что значит "сделай это правилом" ?
В application слое это и называется createClient и в этом методе уже нужно транзакционно сделать и счет и клиента.
Что значит "сделай это правилом" ?
SP
А если в разных, что меняется?